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ABSTRACT 


The primary objective of this thesis is to provide the Marine Corps with a 
thorough bottom up System Analysis of the next generation billet advertisement system 
that will replace Reserve Duty Online (RDOL). The study includes a detailed systems 
analysis, a generic architecture, logical data models, process models and a system model 
which provides the Marine Corps with a blueprint of the requirements for the next system 
of record. The secondary objective of this thesis was to analyze current system 
architectures that advertise and fill job vacancies within the Department of Defense 
(DoD), as well as commercial-off-the-shelf (COTS) products in order to identify what 
architecture should be leveraged by the Marine Corps during its next build. 

In the midst of the long war, it is clearly evident that the reserve is an integral part 
of the Marine Corps total force. This integration hinges on the recognition that the ability 
for our reservists to be able to easily search and identify available opportunities is of the 
utmost importance. The proposed architecture and requirements analysis presented in this 
thesis will provide a solid foundation for the development of a next generation system. 
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I. 


INTRODUCTION 


A. BACKGROUND 

Generally accepted knowledge indicates that the U.S. Marine Corps system for 
soliciting and staffing reserve billets is relatively fractured, redundant, geographically 
dispersed and inefficient for administrators and users. This research was conducted to 
assist the Marine Corps Manpower Information Technology (MIT) branch at the 
Manpower and Reserve Affairs (M&RA) department of Headquarters Marine Corps. A 
systems analysis was conducted to create an improved billet advertisement system for the 
Marine Corps Reserve, including identifying system requirements, developing a logical 
generic architecture, and providing a proposed system architecture for improving the 
system. 

B. OBJECTIVES 

The current system called Reserve Duty Online (RDOL) was meant to be a one- 
stop location for Reservists to look for and apply for different billets available for 
reservists to fill in support of the Marine Corps [1]. Funding shortfalls and organizational 
buy-in issues contributed to a system often referred to as fractured and lacking in the 
functionality needed to meet the objectives of the system. 

This thesis provides the Marine Corps with a “roadmap” or outline to replace 
RDOL. The roadmap is comprised of a detailed systems analysis, a generic architecture, 
logical data models and process models which provide the Marine Corps with 
documentation to develop a new system of record. 

A secondary outcome of this thesis was to analyze current system architectures 
that advertise and fill Department of Defense (DoD) job vacancies, including analyzing 
commercial-off-the-shelf (COTS) products. The goal was to determine the extent to 
which alternative architectural attributes can be leveraged by the Marine Corps to build 
its next generation system. Desirable attributes were incorporated into the design of the 
generic architecture. 
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C. RESEARCH QUESTIONS 

The following are the main research questions addressed in this thesis: 

1. What is the efficacy of the current technological process whereby the Marine 
Corps solicits and staffs billets to existing reservists, i.e., how well is Reserve Duty 
Online (RDOL) working? 

2. To what extent can emerging methodologies and technologies be used to 
fundamentally improve the overall process? 

3. What does a generic architecture of an ideal billet advertisement system look 

like? 

D. SCOPE 

The scope of the thesis encompasses how the Marine Corps currently publishes 
and processes reserve billets through the Reserve Duty Online (RDOL) web-enabled 
application, including recommendations for future system iterations. Within the context 
of this domain, the handling and utilization of member’s resumes and applications was 
also examined. The thesis does not address how applications and resumes are utilized in 
the order writing process, but does address systems interface issues. 

E. METHODOLOGY 

This thesis subscribed to a bottom-up approach which focused on the lowest level 
components first to discover the requirements of the system. The requirements were then 
used to build the logical models that are presented to the Marine Corps for use in the 
design of its next system. To accomplish this strategy, the following two methodologies 
were used to analyze how the Marine Corps advertises and solicits reserve billets: 

1. Framework for the Application of Systems Thinking (FAST) 

2. Architecture Tradeoff Analysis Method (ATAM) 

From each of these methodologies, a subset of prescribed steps applicable to the topic 
domain was utilized. These “subsets” were synthesized and juxtaposed to form a hybrid 
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methodology used to address the Marine Corps problem domain. The following is a brief 
introduction to each methodology and the steps that were used. 

1. Framework for the Application of Systems Thinking (FAST) 

FAST is a hypothetical methodology introduced in the text, Systems Analysis and 
Design Methods by Jeffery L. Whitten and Lonnie D. Bentley [2]. Even though the 
methodology is labeled “hypothetical”, it still contains feasible and practical 
methodologies applicable for problem solutions. In short, it is an iterative and inclusive 
approach constructed of industry best practices. Its structure also allows the analysis to be 
responsive and flexible to different inputs and requirements. Model flexibility is crucial 
due to the breadth of input provided by system stakeholders and owners. 

FAST is an eight phase process, of which the following four phases were utilized: 
scope definition, problem analysis, requirements analysis and logical design. Each phase 
is iterative producing results and milestones documented in the next phase. Fisted below 
is a brief discussion of the composition of each phase and the deliverables for each phase. 

1. Scope Definition: The purpose of this phase is to determine if the problem is 
worthwhile, as well as, determining if the breadth of the scope is within the realm of 
possibility. Deliverables for this phase include a detailed problem statement and 
identification of constraints. 

2. Problem Analysis: This phase examines the existing systems and their 
interactions. The results of the analysis provide designers with an understanding of the 
current system and its problems. From this understanding, business requirements and 
criteria are defined which are used as the basis for Measures of Effectiveness (MOE) 
used to evaluate the system. 

3. Requirements Analysis: This phase determines what the system should do, as 
well as defining and prioritizing business requirements. Specifically, this phase defines 
system functionality, data needing to be captured and stored and system capabilities. This 
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phase does not define technical specifications; rather it defines and prioritizes business 
requirements. The completed deliverable is a Business Requirements Document for 
modeling the new system. 

4. Logical Design: This phase converts business requirements into a systems 
model. The systems model is used to ensure completeness and to identify missing 
functionalities or data requirements. This phase generated Logical Data Models and 
Logical Process Models. 

2. Architecture Tradeoff Analysis Method (ATAM) 

ATAM is an architectural evaluation methodology presented in Evaluating 
Software Architectures: Methods and Case Studies by Paul Clements, Rick Kazman and 
Mark Klein [3]. This methodology focuses on how well architecture addresses the 
quality attributes or goals required by stakeholders. It also provides an understanding on 
how different quality attributes or goals interact with each other. ATAM was chosen 
because it is a proven method providing needed structure during the architectural analysis 
process. This structure helps ensure that all system requirements are identified. Both of 
these characteristics make this methodology ideal for this problem domain, as they 
address a known RDOL core deficiency: a lack of understanding of stakeholder 
requirements. 

The ATAM is a nine step process that investigates how well an architecture that is 
chosen and designed satisfies a particular set of quality goals, and it provides insight on 
how well the quality goals identified interact with each other [3]. The nine steps of the 
ATAM are: (1) the ATAM is presented to the client; (2) business drivers are identified 
and presented; (3) the architect presents the architectural methodology; (4) the architect 
identifies architectural approaches for addressing the problem domain; (5) the architect 
generates a quality attribute utility tree; (6) the architect analyzes the different 
architectural approaches; (7) the architect creates scenarios used to test the architecture 
against the quality attributes; (8) the architect evaluates the architectures using the 
scenarios generated; and (9) the architect presents and explains the results [3]. These 
nine steps are presented in Figure 1, and are divided into the following four functional 
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groups: presentation group, investigation and analysis, testing and reporting group. Of 
the nine steps, four through eight were used. Steps one through three was not utilized 
beeause the requirements dietated in eaeh of the steps were eompleted by a phase in the 
FAST methodology. Step nine’s requirements are ineorporated into thesis eonelusions. 


Presentation 

Investigation & 

Analysis 

Testing 

Reporting 

1. Presentation of 

ATAM 

4. Identify the 

architectural 

approaches 

7. Brainstorm and 

prioritize 

scenarios. 

9. Present the results 

2. Presentation of 

Business Drivers 

5. Generate the 

quality attribute 

utility tree 

8. Analyze the 

architectural 

approaches using 

scenarios 


3. Presentation of 

Architecture 

6. Analyze the 

architectural 

approaches 




Figure 1. Steps of the AT AM 


We began the tradeoff analysis with the identification of architectures. This step 
correlates to step four of the nine step process introduced earlier. Within this step the 
different architectural approaches or styles are identified but not analyzed. Each 
architectural style describes the component types and their topology, and describes how 
data is patterned and controlled [3]. During this step the best architecture for this 
problem domain is identified, including pros and cons of relevant styles. The point is to 
gain an increased understanding of the strengths and weaknesses of the high level 
architecture model, including providing a baseline for subsequent analysis. 

Step five generates a quality attribute, four-node tree (qatree) which identifies, 
prioritizes, and refines important quality attribute goals. Leveraging this tree is meant to 
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capture stakeholder requirements. The first level of the tree is the “utility” apex. The 
second level identifies the quality attributes for the system which are further refined on 
the third level. The forth level (the leaves) prioritize specific, quality attribute 
requirements [3]. These “fourth level requirements” are presented in the form of 
scenarios which are used to evaluate the validity of the architecture being proposed. 
These scenarios are used and refined in steps six through eight to prioritize and select the 
most desirable architectural solution. 

F. ORGANIZATION OF STUDY 

The remainder of this thesis is organized as follows: 

Chapter II provides an overview of the Marine Corps Reserve, how billets are 
currently solicited and staffed, and an analysis of current RDOL problems. Chapter III 
describes and outlines the methodologies employed during the architectural design and 
systems analysis. Chapter IV identifies and analyzes current architectural designs that 
may provide the framework from which the next system can be designed. Chapter V 
presents the architectural vision, validated through use of scenarios. Chapter VI ties the 
results of the systems analysis to the generic architecture presented in Chapter V. 
Specifically, the data captured during the systems analysis was used to build the process 
and logical models, which are presented with their corresponding generic components. 
Chapter VII summarizes the study providing conclusions, recommendations and areas for 
future research. 
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II. MARINE CORPS RESERVE AND CURRENT SOLICITATION 

METHODS 

A. BACKGROUND 

Due to the wartime operational tempo throughout the Marine Corps, an increasing 
demand has been and will continue to be placed on the Marine Corps Reserve, which has 
made an extraordinary contribution both here at home and abroad. The importance of 
placing reserve Marines into appropriate billets is critical because they provide essential 
support and augmentation of the active component of the Marine Corps. Getting the right 
Marine in the right position in a timely manner in a wartime environment is paramount. 
This chapter discusses the history, background, and current status of the way in which the 
Marine Corps solicits and staffs various types of reserve billets. 

1. Marine Corps Reserve 

As of May 2007, the Marine Corps Reserve is comprised of over 33,359 Marines 
in Selected Marine Corps Reserve (SMCR) drilling reserve units from across America 
and Puerto Rico, over 2,576 Individual Mobilization Augmentees (IMA), 2,211 Active 
Reserves (AR), and nearly 60,000 Individual Ready Reserve (IRR) Marines. This is the 
pool of capabilities drawn upon to augment the SMCR or Active Component (AC) [4]. 
For the past six years the Marine Corps Reserve Component has augmented and 
reinforced the Active Component in support of the Global War on Terror. As of March 
2007, 41,560 Reserve Marines have been mobili z ed since 11 September 2001 [5]. 

2. Types of Marine Corps Reservists 

The Marine Corps Reserve is composed of the Ready Reserve, which includes the 
Selected Marine Corps Reserve (SMCR) and the Individual Ready Reserve (IRR), the 
Standby Reserve, and the Retired Reserve. Figure 2 depicts the types of reserve 
categories in the Marine Corps Ready Reserve. A brief description of each follows. 
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Figure 2. Marine Reserve Types 


The largest group is the Individual Ready Reserve which consists of Marines in 
the Ready Reserve not affiliated with the SMCR who: (1) have not completed their 
Mandatory Service Obligation (MSO); or (2) have completed their MSO and are in the 
Ready Reserve by voluntary agreement; or (3) have not completed their MSO (are 
mandatory participants), but are transferred to the IRR during unique situations [6]. 

The second largest group in the Marine Corps Reserve is the Select Marine Corps 
Reserve (SMCR). SMCR units are located in 187 Reserve training centers across 
America and consist of more than 17,500 Reserves from 4th Marine Division (4th 
MARDIV); 8,500 from 4th Marine Logistics Group (4th MLG); 8,000 from 4th Marine 
Aircraft Wing (4th MAW). Members of the SMCR typically drill one weekend per 
month, and attend two weeks of annual training (AT) [4]. 

Individual Mobilization Augmentees (IMA) are Marines that are members of the 
SMCR, but are not members of a drilling SMCR unit. The IMA program provides a 
source of trained and qualified individuals to fill individual billets which augment the 
active component structure of the Marine Corps, Department of Defense (DOD) or other 
Departments or Agencies of the Government. IMA Marines fill billets contained on 
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Active Component Tables of Organization (T/0) and upon mobili z ation continue to 
perform the same type of duty that they do when they are drilling [7]. 

Active Duty Operational Support (ADOS), which was formally known as Active 
Duty Special Work (ADSW), is designed to provide the Marine Corps a means to utilize 
Reserve personnel of appropriate grades and skills, through short tours of active duty, to 
provide personnel augmentation for both Active and Reserve forces to accomplish special 
projects, and to meet operational, administrative, and exercise support requirements of a 
temporary duration. It provides opportunities for Reserve Marines in the SMCR and IRR 
to support short-term requirements, special projects, exercise support participation for 
both the Active and Reserve forces. ADOS Marines are assigned to major Marine Corps 
bases and stations, headquarters, and reserve unit locations as needs are identified by 
Operational Sponsors [8]. 

The Active Reserve (AR) program consists of Reserve officers and enlisted 
Marines who serve in selected, full-time active duty billets. The primary mission of AR 
Marines is to support the organization, training, retention, and administration of the 
Marine Corps Reserve. The AR program allows Marines an opportunity to serve on 
active duty and qualify for retirement benefits after 20 years of service [9]. 

The Reserve Counterpart Training (RCT) program is designed to provide 
members of the IRR an opportunity to improve military skills by training with their 
Active Component counterparts. This program enables members of the IRR, an 
opportunity to volunteer annually for assignments to Active Duty Training (ADT) at 
designated AC commands or for Annual Training (AT). The program is specifically 
designed to upgrade and maintain MOS and technical skills considered essential upon 
mobilization [10]. 

B. CURRENT SOLICITATION PROCESS 

The current manner in which the Marine Corps solicits and staffs reserve billets 
utilizes various methods including website advertisement via Reserve Duty Online 
(RDOL), word of mouth, and hastily posted spreadmarts. A spreadmart refers to a 
situation where spreadsheets containing valuable corporate data are duplicated 
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uncontrollably and modified differently by different users producing a situation where 
each file presents a different version of the "truth" [11]. RDOL was originally designed to 
be the primary, required method to advertise vacant reserve billets. As noted earlier, the 
goal, ultimately, was to make RDOL the “one-stop” web portal where reservists were 
able to not only search and apply for different types of reserve billets, but also receive 
career guidance as well. Specifically, the designers of RDOL envisioned that the site 
would provide access to valuable career information that could be leveraged by reservists 
to dynamically manage their career and maximize their utility for the Marine Corps. But, 
as depicted in Figure 3, poor design and lack of funding has left the application missing 
many required user functionalities, which has led to an apparent decrease in use and 
further deterioration of the system. Many organizations publish vacant billets on their 
own websites vice on RDOL. A quick web survey in February 2008, found that the two 
largest Marine Corps Reserve websites (Marine Forces Reserve/Marine Corps 
Mobilization Command) have resorted to advertising reserve billets themselves. To 
further emphasize this point, the results of a functionality assessment conducted in 
September 2006 by infoReliance found that RDOL usage has dropped significantly since 
August 2005 and was attributed to an overall laek of awareness of the site itself [1]. 
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1. Problems with Current Systems 

RDOL problems can be divided into front-end problems and back-end problems. 
The front ends of information systems support business functions extend out to 
organizational customers [2]. Currently RDOL’s front-end user interface is not intuitive 
and lacks in functionality. The poorly designed user interface encourages end-users to 
revert to alternative methods of accomplishing tasks. The following are some specific 
examples of critical functionality missing from the front-end of the RDOL current 
iteration: 

a. The search page contains several redirects to other sites that takes the user 
away from the principal reserve billet search page with no way to navigate back to it. 

b. Standard search functionality does not allow the ability to sort the results 
of a search. 

c. Some of the advertised functionalities are non-operational. For example, 
the distance search function does not work. 

d. There are numerous redundant applications within RDOL that make the 
site inefficient and cumbersome. 

e. There is no ability for operational sponsors to seek out potential 
candidates to fill vacant billets. 

f. Reservists are unable to post their reserve qualification summary 
(resumes) for sponsors to analyze. 

The back end of an information system supports the internal business operations 
of an organization and its suppliers [2]. In its current form, RDOL is a stovepipe system 
isolated from other Marine Corps computer resources having a limited capability to 
communicate with external resources. 

The system also lacks required basic functionality that users require making the 
system unproductive. Some specific examples of current back-end problems include: 
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a. The design of the system’s data storage and data manipulation 
infrastrueture is inadequate. This has led to dirty data being proliferated throughout the 
various databases. 

b. In its current iteration, RDOL is missing significant interoperability and 
automation quality attributes. For example, all TFSMS data is hand-entered by personnel 
from Reserve Affairs. 

c. The system has a very limited ability to communicate or integrate with any 
other systems. Currently all personnel and table of organization (unit information) has to 
be manually entered into the system, but the system does transmit leads to prior service 
recruiters via the Automated Leads Management Reporting System (ALMRS). 

The previous two lists are not all encompassing. There are additional system 
problems, but the lists do capture a flavor of the inefficiencies. Many of these problems 
may be attributed to ad hoc, incremental process through which the system was built, 
evidently with no architectural plan or useful framework. Figure 4 is provided as a 
descriptive summary of system incongruence’s. 
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Figure 4 depicts the current inefficient configuration of the Marine Corps Billet 
Advertisement System. No known architecture exists for the RDOL system, and the 
various enterprise-level systems cannot communicate with each other, e.g., multiple 
systems have no way to share or leverage applicable resources resulting in substantial 
amounts of rework, duplication and user frustrations. 
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III. DEPARTMENT OE DEEENSE RESERVE RECRUITMENT 

PROCESSES AND SYTEMS 


In order to ensure that the variety of best practices available are captured, other 
Department of Defense reserve recruitment processes were analyzed, including an 
examination of the Air Force’s Volunteers in Professional Service (ViPS), the Navy’s 
APPLY system, and lastly Monster government solutions. 

A. AIR FORCES VOLUNTEER’S IN PROFESSIONAL SERVICE (VIPS) 

In the spring of 2005, the Air Force Reserve established a Volunteer Process 
Working Group and Integrated Process Team (WG/IPT) in order to improve the process 
of matching reservist volunteers to employment opportunities. One of the main focuses 
of this working group was to evaluate and analyze potential candidate solutions for a 
future system. The main objective was to focus on capturing the functional requirements 
in order to develop a volunteer matching system prototype. In October 2005, the Air 
Force Reserve contracted Science Applications International Corporation (SAIC) to assist 
the WG/IPT in formally detailing requirements and help with the examination of 
potential candidate solutions [12]. 

1. VIPS System Functionality 

Many of the processes within the ViPS program are currently fully functional 
within RDOL. Instead of covering every function of the ViPS program, the following 
section will examine the useful processes within ViPS that could be particularly useful 
for RDOL. Although there are hundreds of processes in both ViPS and RDOL, this 
section will discuss those found to be of the greatest utility. Each of the processes is 
listed by functional area (Reservist, Employer, Manager, and Administrator). 

2. VIPS Features for Reservists 

The Air Force ViPS web application has brought together every type of reserve 
opportunity and has truly created a “one-stop-shop”. In addition to being able to view 
volunteer assignment opportunities, a ViPS user has the ability to submit their profile for 
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consideration to multiple job postings, apply to volunteer for billets (Figure 5), and even 
eoordinate ehain of command approval if necessary. 


Vfps 


■ • Volunteers In Profession**! Service^ 
lome My Proti'O My AppkcatMMl* 



^ ^ In fl 
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VIPS Application Form 


Currant Status Maj John Smith has 2 Applications that ara in procass 

Application for: Project Manager, Weisbaden, GE 
Assignment Datas: 01 May 2006 • 30 May 2006 

Description: SERVES AS CONSTRUCTION PROJECT MANAGER TO OVERSEE CONSTRUCTION AND CONTRACTOR WORK ON 
CONSTRUCTION SITES AT USACE EUROPE DISTRICT OFFICE AT RAMSTEIN AFB. GERMANY 


AFSC 


02630 


Years Experience in AFSC 


Reserve Status 


Tradrtional Reservist 


Contact Information: 
Phone I 


Phone (an) Q 


Email 


Email (alt) | 


Approval Chain of Command: 


Position; 

Level 1 Supervisor 
Level 2 LRO 

Level 3 Wlr>g Commander 


llanie; 

Capt John Smith 
Maj Tom Franks 
Col Joanrw Lewis 


Phone: 

(xxx)xxx-xxxx 

(xxx)xxx-xxxx 

(xxx)xxx-xxxx 


Primary Email; 

xxxx@xxx.xxx 

xxxx@xxx.xxx 

XXXX@XXXJOCX 


Secondary Email: 

XXXX@XXXJCXX 

XXXX@XXXJ<XX 

XXXX@XXXJCXX 


Comments: 




Applicable Civilian Skills; 


Attach Resume; 

Professional Engineer H K 
Pentagon D IZ 


lEJSS 

VPO9210 

VP09127 


Assignment Qualifications: 

O Do you possess Contracting Officer Representative Certification? 
C] Do you have experience working with German contractors? 
n Have you completed Safety Manager training? 

(~) Do you possess Professional Engineer Certification? 

□ Do you possess a Top Secret Clearance? 




Location 

Daw 

Status 



Typ« 

Expiration Date 

Action 1 

‘ . ' GE 

01 M 

aV lug Apf-- 



Cm 1 : 'W 


■ m 


C6 ac r-: ■■ 

.-V. ••■•1 

: ■•j . : 


Conbi. 

IV Feb 06 

m SB 


Sccuiity and Privacy Notice 


Figure 5. ViPS Application Form 


One function that is highly desired in RDOL is the ability to manage an electronic 
Reserve Qualification Summary (RQS) with data populated from MCTFS and free text 
blocks [13]. As noted in Figure 6, the reservist has the ability to manage their profile by 
adding the following information: preferred AFSC, which is analogous to a Military 
Occupational Specialty (MOS), assignment duration, assignment location, dates 
available, and if they wish to receive solicitations from organizations. 
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Figure 6. ViPS Profile Page 


The user friendly dashboard is another useful benefit that automatically notifies 
the user of new opportunities and events as seen in Figure 7 each time he/she logs in. 
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Figure 7. 


User Dashboard 


One great additional feature is the ability to, “Email to a Friend” function that 
allows a user to email a posting to another member of the reserves. Even in our high tech 
world of web marketing with banners and scripts, word-of-mouth still remains one of our 
most powerful tools, which this feature allows us to leverage. 

3. VIPS Features for Employers 

Similar to Operational Sponsors/Billet Managers utilized in the Marine Corps 
Reserve billet process, ViPS divides the category of employer into requisitioner and 
broker. The requisitioner is more of a basic role that performs queries and does the initial 
input of the billet; the broker on the other hand is usually a program manager that has 
greater roles than the requisitioner. Requisitioners can manage all active Volunteer 
opportunities and create new ones with an easy to use dashboard interface. (Figure 8) 
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Figures. Requisitioner Dashboard 


These added roles include: facilitating the resolution of non-conforming 
applications and validating the approval for volunteer applicants. Similarly to RDOL, 
ViPS allows the ability to advertise volunteer opportunities to the reserve community, but 
more importantly, it allows billet managers to identify qualified reservists to fill 
vacancies through queries of profiles posted by the reserve members. Furthermore, it 
also contains easy to use Template-based opportunity entry, a user-friendly dashboard 
interface to manage requisitions and candidates. Another valuable benefit of ViPS is the 
automated email to solicit candidates and automated notifications to candidates informing 
them of new billets. 
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4. VIPS Features for Managers (Approval Authorities) 

Currently RDOL does not allow for the ability for a reservist to apply for a billet 
or submit any type of application. One great benefit in place in ViPS is the ability for 
approval authorities to route requests through the chain-of-command for 
approval/disapproval (Figure 9). 



AIR l=ORCC= R<=S(=RV(E 


VIPS Approval Workflowinbox 


Volunteer Approval Request for Col Bruce Wilson. 403 Wng Please respond by 09 Feb 06 


Volunteer ID 


TSGT Marvi 


403rd VP09U6 


ID Duration Volunteer Datae 


30 days 


01 Mar 06 30 Ma. ;6 


Volunteer Location 


;.*P8 ‘IV 


DESCRIPTION: 

PERFORM DUTIES THE 0. -REER FIELD TO INCliJOE BUT NOT _tV 'ED TO M' ‘.TAIN JID UPDATE FilES 

AND Fl.i: PLAN, TR .UK STATUS OF EPR'S .\NO DECORATIONS AND PERFORM .'.CRKGROUP MANAGEMENT DUTIES SECRET 
CLE-ATL-NCE REQUIRED 


of Command 


u-apt ■- 

Ml Stan Todds 


Sjr--- 

;ro 


26 Jan 06 
25 Jan 06 


;:rcved 


Approval Comments: 


33Z 








Location 

Duration 

DalM 

1 

VP06115 

N AFB 

•: d.t, 

01 A- 05 i; Ajn C t 


VP02945 

N AFB 

^•0 , 




Sacurity and Privacy Notice 


Figure 9. Approval Process in ViPS 


Typically the request will be routed via system generated emails with links for the 
approver to login to the system to approve or deny. Additionally, once a candidate has 
been approved for a billet, the system automatically modifies the users profile in order to 
“black out” the candidates dates of availability. Managers also have a greater amount of 
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visibility in the system pipeline through the personalized management dashboard 
interface which allows them to see a broad view of their potential reservists, applicable 
billets, and application(s) status. 

5. VIPS Features for Administrators 

Similar to the members of the Marine Corps’ Career Management Team (CMT), 
ViPS administrators are responsible for configuration of the system and its ongoing 
maintenance including establishing roles and access privileges, generating and 
distributing reports, and performing general help desk functions. Unique to ViPS is the 
ability of the administrator to configure and post employment surveys, adjust the 
searching agent, and ability to automatically detect “stale” profiles. One great feature in 
ViPS is the ability of the administrator to adjust the volunteer and opportunity matching 
agents (search by volunteer profile or search by opportunity profile) which can be 
configured by the administrator to assign weights to specific fields to enable accurate 
search results (e.g., AFSC = .25, Available Date Range = .15, Location = .20, etc.). 
Moreover, it can be configured to automatically detect expired or "stale" volunteer 
profiles and allow the administrator to deactivate or archive and automatically notify the 
volunteer (email). 

6. VIPS Conclusions 

Unlike RDOL, ViPS has carried a significant amount of funding behind it, and 
was given a thorough requirements analysis. Over the past three years, the Air Force 
Reserve has worked diligently on developing ViPS. Moreover, ViPS is truly a “one-stop- 
shop” for a reservist seeking employment in the Air Force Reserve. As the Air Force 
owns all of the source code for the ViPS program, future work could be conducted by the 
Marine Corps to address the potential of porting ViPS to become a Marine Corps web- 
enabled application. Although some modifications would be required due to differences 
in our personnel systems, the basic functions of advertising reserve billets remains the 
same. This could potentially save the Marine Corps a tremendous amount of money and 
will be discussed further in the future work section of this thesis. 


21 



B. NAVY’S JOAPPLY SYSTEM 

One of the Navy’s overarching goals is to maximize the readiness of the fleet by 
ensuring that its sailors are appropriately trained and that their skills honed and leveraged 
by ensuring that sailor’s career track is closely aligned to the goals of the Navy. The 
Navy manages this process by providing sailors with dynamic and comprehensive set of 
career management tools to ensure that they meet the appropriate milestones in order 
maximize their career potential. The Naval Reserve career management tools are 
comprise of a three tiered system that addresses different segments of sailors within the 
Naval Reserve [14]. 

The first system of the triad is titled APPLY. APPLY is a web enabled portal that 
is designed to facilitate the screening and subsequent assignment of senior officers into 
positions of leadership and management. The second system is titled Career Management 
System Interactive Detailing System (CMS). It was designed to assist enlisted reservists 
in managing their careers by allowing them to directly communicate with Assignment 
Coordinators as well as providing the resources to search for available billets. The third is 
titled JOAPPLY. JOAPPLY is a component of the APPLY which is designed to help 
Naval Reserve leadership place junior officers in appropriate billets. JOAPPLY also 
provides junior officer’s with a resource in which they can explore career opportunities 
drawn from the entire billet base of the Naval Reserve that is available assignment [14]. 
JOAPPLY aligns closest with what the Marine Corps wants to do with their system so 
our primary analysis will focus on it. 

1. JOAPPLY Background 

After the success of the Apply system for billeting senior leadership in the Naval 
Reserve it was determined that a system needed to be built for the junior officers that 
provided them with similar resources. JOAPPLY was modeled after the CMS system in 
the sense that it was designed to be an interactive and dynamic application that allowed 
junior officers to actively manage their career [15]. The previous system, JASS, only 
allowed sailors to view jobs, and did not provide sailors with an avenue in which they 
could apply for billets they were interested in without the help of a command 
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representative. This process did not provide sailors with the ability to manage their 
career nor did it really give employers any sense on whether the applicants applying for 
vacant billets were qualified. 

2. JO APPLY Process Overview 

JOAPPLY is a four-phase, time driven process. The first phase, depicted in blue 
in Figure 10, allows Operational Support Officers (OSO), program managers, the ability 
to create, read, update and delete advertised billets. It also provides the OSOs with the 
ability to insert comments and provide applicable information about the billets being 
advertised. The second phase, depicted in green in Figure 10, allows Reserve Component 
Junior Officer’s (RCJOs), which are defined as junior officers assigned to the active 
Naval Reserve, to apply for vacant billets in the Naval Reserve as long as they are within 
prescribed detailing windows. The third phase, depicted in yellow in Figure 10, gives the 
OSO and Commanding Officers (CO) the ability to review, prioritize and comment on 
each application made for vacant billets. Ranking and comments can only be done during 
this window. The fourth phase, depicted in red (Figure 10), is where CNRFC N12 
Assignment Coordinators review all applicants, the OSOs and COs rankings and 
comments, then slate the Junior Officers to billets [16]. 
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Application Schedule 



JCkAPPLYAVAJlABLE FORAPPUCATIOriS 

J JOAPPLY AVAILABLE FOR COMMAND COMMENTS ON APPUCANTS (NO Applicationi allowtcl. Command Commonls only) 
H ASSfONMENT COORDINATORS MAKE ASSIGNMENTS 


Figure 10. JOAPPLY Application Schedule 


3. JOAPPLY Stakeholders and Functional Overview 

There are four types of primary users that were identified by JOAPPLY 
requirements document: Reserve Component Reserve Component Junior Officers 
(RCJO), Reserve Component Detailers (RCD), Reserve Component Program Managers 
(RCPM) and Reserve Junior Officer Interactive Detailing Managers (RJOID). Each of 
these different roles is afforded different levels of access to the functionalities of the 
system. Access is based on the position that the JOAPPLY user is filling. 
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RCJOs are the primary business users of the system. That being said, they have a 
dynamic and rich user interface that allows them actively manage their career, as well as, 
search and apply for future positions. Within the context of this thesis, RCJOs correlate to 
a Marine Reserve in the legacy RDOL system, but the Navy’s definition of reservist is a 
more stringent in the sense that the Navy only grants active reservists access to the 
system. 


jtarm' 



You imitl login le jpply 



Figure 11. Login Process for JOAPPLY 

When a RCJO attempts to enter the system he or she must go through the Apply 
system as depicted on the left screen shot of Figure 11. Once the user clicks on the 
JOAPPLY link, the user is routed to the login page and the RCJO then logins in via CAC 
authentication or via password authentication. This is similar to the RDOL process which 
utilizes Marine Online (MOL) LDAP services or password access to authenticate its 
users. After logging in, RCJOs will be directed to their homepage which is depicted in 
Figure 12. The homepage contains two functional sections: The Profile and Registration 
section and the Assignment Tools section. 
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Figure 12. Member’s Homepage 


The first functional section, the Profile and Registration section, contains a 
Current Assignment subsection, a Billet History subsection, a Personal Data and Contact 
Information subsection and a Qualifications subsections. When RCJO signs onto the 
system for the first time they are prevented from accessing other functionality of the 
system until they verify their personnel data, this is depicted in Figure 13. RDOL does 
not currently make a Marine verify their personal information before using the system, 
which causes complications in the selection process. 


Your registration is not complete Please update your profile to complete registration with the APPLY website Please 
address the areas marked in red 

** Current Assignment Last Reviewed on 1/1/2006 
" Billet History Last Reviewed on 6/15/2007 

” Personal Data and Contact Information Last Reviewed on 1/31/2007 
** Qualifications Last Reviewed on t/31/2007 


Figure 13. PR Initial login prompt to update 
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Within the current assignment subsection (Figure 14) the user must verify that all 
of their current billet information contained within the system is correct. The information 
displayed comes directly from the Reserve Headquarters System; therefore any 
inaccuracies must be corrected through the member’s parent reserve activity. 



Registration: Current Assignment Information 




Figure 14. Current Assignment Verification 

The Billet History subsection allows the member to verify that their chronological 
billet history is accurate. Members can edit, delete and add historical billet entries to this 
section (Figure 15). 
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Figure 15. Billet History Data 

The Personal Data section (Figure 16) allows the member to verify their SSN, 
Name, Date of Birth, Designator, Rank, Promotion, Date of Rank, Address, Home Phone 
and Work Phone. All the data displayed in this subsection is from the RHS repository, so 
if anything is inaccurate in this section the member needs to contact his or her reserve 
activity to update the information. 
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Figure 16. Personal Data and Contaet Information 


The Qualifications subsection (Figure 17) gives the member the ability to review 
their clearance, their NOBC(s), AQD(s), Subspecialties and any Education entries. The 
goal of this section is to ensure that a RCJOs resume is accurate before it goes before a 
selection board. If RCJO discovers and error there is a matrix was made for a reservist to 
address the mistakes. 
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Figure 17. Qualification Summary 


The second functional section, the Assignment Tools section, allows the reservist 
to actively search and apply for vacant billets, but, as depicted in Figure 18, a RCJO 
cannot view or apply for vacant billets unless they are within 12 months of their PRD and 
their personal information in the Profile and Registration section has to have been 
reviewed by the member. 
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I You must be within 12 months of your PRD in order to Apply for a billet. | 
I If you are outside the 12 month window, you will receive this notice. | 


Junior Officer APPLY 


You have more than 1 year of tenure left in your current assignment You may not leview/apply for a new assignment at 
this time 

" . (note the Browse tool does not allow applications ) 


Figure 18. PRD Alert 



Once a member is within their 12 month PRD window, the RCJO can search and 
apply for vacant billets, view their dreamsheet and view the JOAPPLY schedule. 

When a RCJO navigates to search for a vacant billet by clicking on the “Search 
for Junior Officer Assignments” link (Figure 19) they are able to enter the following 
arguments for their search query: Rank, Designator, NOBC, RUIC, NRA, RCC and 
Program Code. The system uses the Reserve Functional Area and Sex (RFAS) codes to 
match search criteria with available billets. In addition to searching by the 
aforementioned criteria, reservists are able to rank their preferences based on assignment 
location as well as by specific professional attributes [17]. 
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Figure 19. Search Screen Page 


The search results page (Figure 20) will display the Billet Title, Unit Name, 
RUIC, RBSC and Designator of all the results returned by the query. The member can 
then choose to view the details of a billet, navigate to additional results (if applicable) or 
add the job to their dreamsheet. A member can select up to three billets to add to their 
dreamsheet [17]. 
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Figure 20. Search Results Page 


As depicted in Figure 21, when a member navigates to a specific billet’s detail 
page, the unit information, the billet information and command information will be 
displayed. The unit information includes the Name, Short Title, RUIC, AUIC, the reserve 
activity name and the Commanding Officer’s name. The billet information contains the 
billet identification number (BIN), the PRD, the number of applicants, description of the 
billet, rank requirement, command type, RSBC, VRFAS, HRFAS,NOBC requirements, 
drill location, drill frequency, weekend drill and security clearance requirements. The 
command information results section will include the supported command name, mission 
type, location, any comments about the billet from the supported command and 
comments from the commanding officer of the command [17]. This breadth of this 
information gives the reservist an extremely accurate representation of a specific vacant 
billet which ensures that it truly is a job that the RCJO is interested in. 
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Figure 21. Search Details Page 

If a member desires to apply for a billet he or she hits the apply button, and it is 
added to the member’s dreamsheet. Once the application is submitted, the search page 
will update and the member will be able see the “add to dreamsheet” column updated to 
reflect the applied for status as depicted in Figure 22. The member will also receive a 
confirmation email that will be sent to their primary email address. Again, a member is 
only able to apply for three billets at one time, but if the member attempts to add more 
than three billets to his or her dreamsheet then the system will provide the user the ability 
to remove a billet on their dreamsheet in order to accommodate the new application. 
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Figure 22. Updated Billet Status Within Search Results Page 


The dreamsheet will display all the billets that are in the queue of the member. As 
depicted in Figure 23, the dreamsheet page will display the billets name, the unit’s name, 
RSBC, designator and rank of the billet. It will also provide the member with the ability 
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Removing and adding billets and modifying application comments is only 
allowed during the application phase of the JOAPPLY cycle. 




Figure 23. Dreamsheet page 


to remove a billet from their queue as well as include comments for the detailer and 

command representatives to review. A member can only modify or delete billets during 

the application phase of the detail cycle. Once the application phase has closed, the RCJO 

35 





















must wait for the OSO review cycle and the Assignment Coordinator review cycle to 
complete before learning the results of the application process. Whether selected or not 
the RCJO will receive an email informing them of the results of the application process. 
If the RCJO was not selected the process begins over again, and if the candidate was 
selected then orders will be sent to the gaining and losing commands, as well as, to the 
member. 

The acronym RCPM is synonymous with OSO. An OSO’s homepage (Figure 24) 
has the similar look and feel of the RCJO’s homepage, but the management role provides 
the OSO with greater latitude within the system due to requirement of their managerial 
position. Again there are two function sections, in this case the profile and registration 
section is not as dynamic because the required information is captured during the initial 
access process. The section does provide the OSO with the ability to update contact 
information, as well as, access CNRF N12’s administrative tools. 
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The deadline has passed fot applying for Board Mertrbership and Board Support Please refer to the CNRFC Note 5400 
(located under Helpful Links) for more information on the timeline for application decisions 


Figure 24. OSO Homepage 


The OSO Assignment Tools functional section is much more significant, and will 
be discussed in greater detail. When the OSO follows the “Search Jo APPLY Billet” link 
the OSO search page will be called. As depicted from Figure 25, from the search page an 
OSO can search for an individual billet by the Billet Identification Number (BIN), or the 
OSO can search for a group of billets based on their RUIC or the OSO can search for an 
individual billet by using the descriptive search criteria to discover the billet of interest. 
The OSO is also able to filter by whether the job was advertised or not and whether the 
vacancy has applicants or not. 
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Figure 25. OSO Search Page 


Once the submit button is entered a search results page is generated which will 
provide the OSO with the results of his or her query, as well as, provide further 
navigation. Figure 26 depicts the results page and the fields that are editable. The OSO is 
able to edit both the Additional Billet Information and the Supported Command 
Information, but is unable to update the core billet information that is extracted from the 
RHS database. Within the Billet Information section, the number of applicants currently 
in the queue for that particular billet identified by the query will also be displayed. The 
detail page also shows the OSO if a billet will be displayed in the next advertisement 
cycle. 
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Figure 26. Single Billet Results Page 


From the billet results page the OSO is also able view the pool of candidates that 
have applied for the vacant billet. As Figure 27 depicts, the OSO is then able to rank and 
post comments on each candidate, which will be reviewed by the Assignment 
Coordinators during the selection process. 
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Figure 27. OSO Candidate Pool 


The Reserve Component Detailers have very little functionality within the system. 
They are able to perform a generic search form the APPLY homepage. This search will 
provide them with a details page off all the empty or soon to be empty billets in the Naval 
Reserve. If they find a billet that a perspective candidate can fill, they are instructed to 
call a point of contact at NRFS N12. This POC will then be able to gain the new member 
which then allows the member to access the system. This limited functionality severely 
limits the usability of the system for detailers. 

4. JO APPLY Conclusions 

JO APPLY has many attributes that are desirable for the next Marine Corps 

Reserve Billet Advertising System. Billets are tied to Billet Identification Number; the 

system uses this attribute to automatically advertise in the system when they are within 

12 months of them being vacated. Members are able to see, and are forced to update, all 
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of their personal and professional information, which keeps the members actively 
engaged in managing their careers. Members are also able to dynamically search and 
apply for jobs that interest them; this induces and promotes harmony during the process. 
On the management side, OSOs and COs are able to rank and provide feedback on 
potential candidates. This helps commands get the right sailor for the job being 
advertised, which ultimately will improve the readiness of the unit. 

The system also has many undesirable attributes. First the system has little to no 
documentation. And what little documentation that does exist doesn’t correlate to the 
system that is being currently utilized. Second, the system provides very limited 
functionality for the detailers, which makes the system basically useless to them. Which 
leads us directly to the third point; access is limited to members of the active Naval 
Reserve and it provides little access to a potential recruit. Specifically if somebody is 
interested in joining the Naval Reserve they cannot access the system to browse the 
available billets. They have to go to a recruiter, who also doesn’t have access to this 
system, so it is almost impossible for some to easily identify potential billets of interest. 
Finally, the system was designed to curtail the good old boy system by preventing 
preferential treatment of candidates by providing an unbiased application process. 
Unfortunately the current design of the process makes it easy for candidates to be 
discriminated against due to familiarity of the OSO with other candidates. There is no 
checks and balance system to ensure that the OSO is being equitable and fair when 
ranking members. 

C. MONSTER.COM AND USAJOBS.COM 

Monster.com, founded in 1994, is a twelve year old multinational company that 
specializes in online recruitment of potential applicants for vacant positions advertised by 
a plethora of different employers. In its current configuration the corporation has 17 
unique job search networks and 40 international sites which encompass both commercial 
and academic institution portals [18]. This congregation of resources has created an 
impressive data warehouse of potential candidates. In fact, as of June 2007, Monster and 
its subsidiaries housed over 80 million unique job seeker resumes and 50,000 more are 
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added each day [19]. The corporation has also worked diligently at maximizing its brand 
recognition through a complex web of partnerships and community sites. 

According to a Taylor Nelson Sofres (TNS) survey performed in the fourth 
quarter of 2006, their efforts have proved fruitful as 9 out of 10 respondents to a market 
survey recognized Monster.com and its mission [19]. 

The remainder of this section will focus on one of Monster subsidiaries: 
USAJOBs.com. USAJOBS.com is a good example of a potential solution that 
Monster.com can provide the Marine Corps in its endeavor to produce the next iteration 
of RDOL. USAJOBs.com was built as part of the E-Govemment initiative introduced by 
the Bush administration. Its goals were to provide “state-of-the-art on-line recruitment 
services”, serve as a single sign on application point, to provide a competitive advantage 
for government agencies trying to hire top talent and to improve the effectiveness of the 
federal government’s job recruiters [20]. These provide the Marine Corps with a Product 
Line Architecture in which it can achieve its overarching goals of Marine Corps for its 
next system, so it makes it a natural choice to compare and contrast. 

1. Technologies Leveraged by USAJOBs.com 

At the core of USAJOBs.com is an application titled Recruitment One-Stop 
(ROS). This application processes the requests and information submitted by the different 
federal government agencies by calling the appropriate Monster.com resource. Specific 
Monster.com resources deployed in this project include proprietary technologies such as 
Monster Career Center, Monster Officer HQ and its job search engines [20]. These 
resources are melded together with functionality created exclusively for the project in 
order to meet the needs of the federal government. The use of existing technologies with 
new technologies has created a dynamic and professional that has seamless integrated 
commercial products with governmental agencies legacy systems. 

ROS is connected to the government agencies through a proprietary middleware 
application titled Monster Business Gateway (BGW). As exhibited in Figure 28, BGW is 
the only interface between the ROS and the government sites. It uses basic message 
protocols and standards to facilitate communication between the different systems. 
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Specifically it uses SOAP XML requests over HTTP/HTTPS and FTP/FTPS to 
communicate between the BGW and the Agency applications [20]. The protocol utilize 
depends on the data size and the data latency requirements of the function using the 
service. The data itself is stored in a database schema of the users choice. According to 
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Figure 28. Depiction of Monster.com Business Gateway 

Dave Concordia, Monster’s Director of Development for Government Solutions, 
reiterated that Monster can support any type of database from relational databases to 
object oriented databases and anything in between [21]. Monster periodically updates its 
database schemas to reflect the new needs of its customers as well as to keep pace with 
technological advances. But most of these upgrades are backward compatible with 
current systems which make them transparent to the user. 

As shown in Figure 29, the Government Agencies are required to use the World 
Wide Web to transfer information to and from USAJOBs.com. Using the web as the 
medium makes data security and integrity paramount. Monster employs a two pronged 
approach in its attempt to meet these security needs. First the data is transmitted between 
the BGW and the Agency systems via HTTPS or FTPS protocols. The second security 
measure implemented by Monster is the incorporation of an encrypted Customer Access 
Ticket (CAT) into the header of the SOAP message. The CAT uniquely identifies, 
verifies and authenticates a user. Monster distributes and manages a master CAT list, but 
the content of the header is managed by outside agency. Once a user has been 
authenticated. Monster verifies that the individual user has the proper licenses and 
permissions to complete the transaction requested [20]. 
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2. US A JOBS Employer Functional Processes 

Employers are provided a CAT, access and authority to manipulate 
advertisements from the agencies in which they are employed. Monster uses these 
credentials to ensure that they employer has the rights to perform add, delete or modify to 
advertisements within ROS. Employers have the ability to add single or batch 
advertisements. Once the advertisements are posted. Employers have a robust set of tools 
to monitor activity and managing their applications. 

Eor example. Employers are notified when an application is submitted for one of 
their advertisements. Eigure 29 depicts the flow of the application from the ROS to the 
Agency itself. This process provides positive feedback for both the employer and the 
applicant that an application was received and has been processed. In addition to the 
email, the employer can also create a custom message that is displayed to applicant after 
an application is received. One of the disadvantages to this system is that responsibility 
for catching duplicate application submissions is delegated to the agencies; ROS has no 
means to determine if the application is a duplicate. 
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Figure 29. Application Process Path 


3. US A JOBS Applicant Functional Processes 

Once an applicant has found a job of interest he or she may submit a resume to 
apply for the vacancy. As exhibited in Figure 30, USAJOBs resume builder is a four page 
process which covers four areas: personal information, the second area captures a 
member’s experience and education, the third area allows the applicant to enter 
references and any other information that may be pertinent and the forth area allows the 
applicant to review, set interview availability schedules and error check the resume 
before posting [22]. The applicant has the choice on whether to allow his or her private 
data to be publically available for employers to search. Applicants can also delete or 
modify a resume at any time. This resume process was condensed to capture what was 
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relevant to federal job recruiters. This is a significant point because it amplifies that that 
the resume can be designed to focus on the attributes the Marine Corps is genuinely 
interested in. 



Figure 30. Resume Builder Page 


Once the applicant registers and builds his or her resume they can begin using the 
functionalities of the site or start searching for a job. A member can search for a job 
manually or virtually. Virtual searches are done by creating a “search agent” who 
continuously runs a query of your design against USAJOBs job repository. An applicant 
can create up to five search agents to run simultaneously. As depicted in Figure 31, the 
applicant can choose provide the following search criteria: by location, by job category, 
occupational series, by agency, by salary range, by job experience or desire, by position 
title or by keyword. If a positive search result is returned the site emails you the positive 
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match within a prescribed amount of time that the user sets. By having five unique search 
agents an applicant can cover a wide spectrum of job interests [23]. Once the search agent 



Figure 31. Job Search Agent Selection Page 


is created the user can actively manage them from a customized Current Job Search 
homepage. This homepage will allow you to view, modify, delete or add additional Job 
Search Agents. These attributes and functionalities match significant core requirements 
for the Marine Corps proposed system. 

The applicant can also search for jobs manually. The member has the ability to 
search by keyword, by agency, by Federal Series code, by job detail (location, salary, 
combination etc.), or by senior executive search. The results of the query are presented by 
either the age of the advertisement, newest to oldest, or by the keyword relevance [24]. 
As shown in Figure 32, the query results give the title of the position, the agency that is 
hiring the position, and where the vacancy is located geographically. A member can click 
on the job title for a detail description of the requirements of the vacant position. At the 
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bottom of the detail description of the job posting is the information on how to apply for 
the position. Due to system limitations, whether the agencies or Monsters, you can not 



Figure 32. Manual Job Search Results 


apply for every position online through USAJOBs.com [25]. If the applicant is unable to 
apply through USAJOBs.com, the applicant will either have to mail via US post or follow 
an external link to the agencies site to finish the application. A member also has the 
ability to email the job listing to a friend or print a hard copy if they so desire. Once the 
member has applied for the position, he or she has the ability to track the application as 
well as view their application history for the past 18 months [25]. 

4. USAJOBS Conclusions 

Monster.com solutions provide users and organizations with many built in 
advantages that match the Marine Corps desired quality attributes. First, the core 
technologies of their product remain the same, which provides the system with innate 
ability to reuse many of the technologies. Second, being a turnkey solution, the product 
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can be up and running in a much shorter period than building a product from scratch. 
USAJOBs.com took less than six months to deploy the first iteration of the product. 
Three, the life cycle a cost of the product are lower than those of a proprietary system as 
Monster updates and maintains the core part of the system as part of the contract. Four, 
the product will be exposed to much broader market of the consumer base that the Marine 
Corps is trying to reach as the product will be crossed advertised in other Monster 
products and communities. 

Monster does have a few disadvantages. The initial cost, up front will be higher 
than building a system from scratch. Second, security, though addressed, is weak at best 
and seems to be an afterthought in the process. Third, the model assumes that have access 
to the web and that it will always be available. This is not unreasonable, but redundancy 
needs to be built into the system to guarantee the connectivity that Marine Corps desires. 
Forth, ROS has no built in capabilities to recognize duplicate applications. The onus for 
this task falls squarely on the shoulders of the different agencies which could lead to 
redundant applications and dirty data contaminating their data repositories. And last, the 
Marine Corps has many legacy systems that do not have XML messaging capabilities 
which is the cornerstone to this model. This will require additional middleware that was 
not recognized in the model presented for USAJOBs.com. 
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IV. REQUIREMENTS ANALYSIS EOR NEXT GENERATION 
MARINE CORPS BILLET ADVERTISEMENT SYSTEM 


This chapter will focus on identifying the Marine Corps requirements for their 
next reserve billet advertisement system. One of the primary reasons the Marines current 
billet solicitation system failed was due to the lack of requirements analysis at the 
inception of the project. Specifically, the requirements were defined by a small group of 
subject matter experts rather than conducting a comprehensive requirements analysis with 
all the applicable stakeholders. This led to a fragmented and incomplete system. To 
ensure that this doesn’t occur again, we made a concerted effort to make sure that all of 
the stakeholders were included in the requirements analysis. This was done by 
conducting phone interviews, analyzing systems with similar functionality, as well as, 
using a focus group facilitated by a professional system designer. These efforts yielded a 
robust set of documents in which we were able to leverage during our analysis. 

The results of our requirements analysis gave us a firm understanding of what the 
stakeholders required, and we expanded upon these results by breaking them down into 
the Data Business Requirements and the Process Business Requirements of the next 
reserve billet advertisement system for the Marine Corps. We discuss first the Business 
Data Requirements which allowed us to build the logical data model of the system. This 
logical model will provide the blueprints for the implementation of the next generation 
system. After we completed the logical model, we proceeded on to identify the Business 
Process Requirements. During the discovery of the process requirements, the system’s 
Context Data Flow Diagram (CDFD), Functional Decomposition Diagram (FDD) and its 
associated Use Cases and Process Models were produced. The process models provide 
the building blocks to construct the system’s sub-system diagrams. The combination of 
these two requirements, the data and process requirements, will give the Marine Corps a 
solid foundation on which to build their next generation system. 
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This chapter is organized in the following manner: First we define and depiet our 
data model, seeond we design the CDFD, third, using the CDFD as a guide, we design 
the systems FDD and its assoeiated eomponents and finally we present the four sub¬ 
system diagrams. 

A. DATA MODEL 

After eareful analysis of all the information gathered a root data model was eonstrueted. 
This is an important step because a data model identifies the underlying data structure for 
the next system. There are several ways to model the data structure, but we used the 
entity relationship diagram (ERD) method. We ehose the ERD methodology because it 
not only identifies or captures the data entities that the system needs to capture, but it also 
defines the relationships between those different sources of data [2]. The core ERD for 
the Marine Corps Reserve is depieted in Eigure 33. As with any data model, this should 
not be eonsidered the conelusive model for the project, and it should be 



Eigure 33. ERD Data Model 
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noted that data structures need to be continually modified to reflect the current state of 
the system that it supports. To create this ERD, we first combed through all of our 
interviews and notes from our requirements analysis which allowed us to discover our 
main entities, their attributes and the relationships between the different entities. We then 
normalized the rough data structure to second normal form. 

The results of our analysis yielded four main sub-groups within the body of the 
ERD: Candidates, employers, managers and recruiters. Candidates are Marine Corps 
Reservists that are actively using the billet advertisement system to seek out employment 
opportunities. Their personal data is automatically populated in the model from an 
external Marine Corps Enterprise System. The database will also capture data on the 
candidate’s personal section of his or her Reserve Qualification Summary, their 
application history, their personal web-portal settings, as well as, their current and 
historical subscriptions to employment search engines. 

Employers are any Marine Corps or external activity that wants to advertise 
vacant employment opportunities within the Marine Corps Reserve billet advertisement 
system. The database will capture the employer’s personal information, their historical 
and current advertisements, their personal web-portal settings, as well as, their historical 
and current candidate search subscriptions. 

Recruiters are any Marine Corps Reserve Recruiter who leverages the system to 
identify potential candidates and employment opportunities for prospective recruits. The 
database will capture the recruiter’s personal information, their assigned recruiting 
region, their personal web-portal settings, as well as, their current and historical candidate 
search and employment search subscriptions. 

The four main sub-groups are tied together via relationships that were identified 
during the requirements analysis. We will expand upon the main relationships that exist 
between each of the main entities identified starting with the Candidate’s relationships. 
One of the primary reasons a Candidate uses the system is to search for employment, 
therefore a significant relationship exists between a Candidate and an Employer. 
Specifically a Candidate can submit multiple applications for an advertisement, and 
conversely an advertisement can have multiple candidates applying for it; therefore, these 
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two entities have a many-to-many relationship. In order to apply for a vacant billet, a 
Candidate must have a current resume. A candidate can have many resumes, current and 
historical, but a resume only contains the information of one candidate. A candidate also 
can have only one MOS, Rank and Reserve Category while all three of these entities can 
be associated with multiple candidates. To assist the Candidate in searching for desirable 
employment, they will be able to subscribe to search services. A candidate can have 
multiple subscriptions and a type of subscription can be assigned to many candidates. 
Any active subscription for a Candidate generates leads of interest. A Candidate can have 
many leads and a generated lead will be disseminated to any Candidate whose 
subscription settings match the lead’s attributes; therefore, it is a many-to-many 
relationship. A Candidate can also submit a trouble call, but a trouble call can have only 
one creator. In order to use any of these resources that Candidate has to be assigned a 
user role by a Manager. A Candidate can be assigned multiple roles, active and historical, 
and a type of role can be assigned to numerous Candidates. 

An Employer’s relationships focus around the management and maintenance of 
billet advertisements. An Employer can create numerous advertisements, and each 
advertisement can have multiple applicants. Therefore, a many-to-many relationship 
exists between an advertisement created by an Employer and the applications submitted 
in response to the advertisement. Each advertisement also correlates to only one vacant 
billet, but a billet over its life may have many advertisements. Each billet is assigned to 
only one command and each command can have multiple billets. To assist the Employer 
in searching for candidates to fill their vacant billets, they will be able to subscribe to 
search services. An Employer can have multiple subscriptions and a type of subscription 
can be assigned to many Employers. Any active subscription for an Employer generates 
leads of interest. An Employer can have many leads and a generated lead will be 
disseminated to any Employer whose subscription settings match the lead’s attributes, 
therefore it is a many-to-many relationship. An Employer can also submit a trouble call, 
but a trouble call can have only one creator. In order to use any of these resources an 
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Employer has to be assigned an Employer role by a Manager. An Employer can be 
assigned multiple roles, active and historical, and a type of role can be assigned to 
numerous employers. 

At the heart of the Recruiter’s relationships is the active search for viable 
candidates to fill vacant billets that exist in the Marine Corps. To assist the Recruiter in 
these efforts they will be able to subscribe to candidate and billet search services. A 
Recruiter can have multiple subscriptions and a type of subscription can be assigned to 
many Recruiters. Any active subscription for a Recruiter generates leads of interest. A 
Recruiter can have many leads and a generated lead will be disseminated to any Recruiter 
whose subscription settings match the lead’s attributes, therefore it is a many-to-many 
relationship. A Recruiter can also submit a trouble call, but a trouble call can have only 
one creator. In order to use any of these resources, a Recruiter has to be assigned the 
appropriate role by a Manager. A Recruiter can be assigned multiple roles, active and 
historical, and a type of role can be assigned to numerous Recruiters. A Recruiter is also 
assigned to a geographical area of responsibility, but a geographical area can have 
multiple recruiters assigned to it. 

The Manager’s relationships are tied to their primary responsibilities of role 
management and system maintenance management. A Manager is responsible for 
assigning roles to the user of the system and they can also be assigned multiple roles, 
active and historical, and conversely a type of role can be assigned to numerous 
Managers. Managers are also a responsible for managing the trouble call queue for the 
system. A manager can be responsible for multiple trouble calls, and a trouble call can 
have many managers who are responsible for it over its life. Each Manager is able to 
broadcast numerous system messages, but each message can only be created by one 
Manager. 

B. CONTEXT DATA FLOW DIAGRAM 

After defining the data model, the next step in our prescribed methodology is to 
identify and model the Business Processes. Process modeling provides stakeholders with 
a firm understanding of the structure and flow of data through systems construct from the 

view point of the system users and owners [2]. The goal of these models is to remove any 
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biases or preconceived notions that were created or formed based on the current iteration 
of the system. For this analysis this is particularly important, because the current system 
lacks a sound foundation and was poorly built, which has led to many ill conceived 
opinions about the system and its future. These models will also reduce the risk of 
missing business requirements, because it will allow us to provide stakeholders with a 
pictorial representation of the proposed system which will afford them the opportunity to 
review the proposed system in detail to ensure that none of their requirements are missed. 

The first component of the process model that we designed was the Context Data 
Flow Diagram (CDFD) which is depicted in Figure 34. The CDFD provides the 
stakeholders with an overview of the scope of the system. We created this diagram by 
viewing the proposed system as a "black box." From this perspective, in order to 
determine what inputs the system, we asked during interviews what external systems and 
inputs did the new system need to respond to. After determining what the inputs were, we 
then identified the outputs and external data stores of the system were by asking users 
what responses must be produced by the system and where these responses are stored. It 
is evident from this model that the underlying structure identified in the data model holds 
true. Specifically, there are four significant external users of the system: Candidates, 
Applicants, Employers and Recruiters. At this level, the functionality defined in the data 
model for the Candidate is encapsulated by the Candidate and the Applicant Modules in 
the CDFD. The Candidate, in this case, represents a potential recruit who wishes to “see” 
or “browse” for opportunities that exist within the Marine Corps, and an Applicant 
represents a Marine who is already in the system and is actively applying for vacant 
positions. 

The CDFD also depicts the system’s ties to several external Marine Corps data 
repositories and legacy systems, as well as, identifies areas of potential growth. The 
Monitor Module was included in the CDFD in response to input provided during 
interviews described future capabilities that may be incorporated into the RBAS system 
in the future. Currently the Marine Corps Reserve does not have dedicated monitor for 
reservists, but may so in the future. That being said, our intention from this point forward 
is not to include this module in our analysis, but we decided to leave it in the CDFD to 
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emphasize the importance of ensuring that the Marine Corps building or purchasing a 
system that has the capacity to grow dynamically with the ever changing needs and 
demands of the Marine Corps Reserve. 

A few examples on how external systems and inputs interact with the system will 
make the relationships that exist between the different systems more apparent and easy to 
understand. Candidate external systems will be able to will be able to dynamically search 
the RBAS for billets that match the criteria entered into job search query, and RBAS 
return the results off the query in turn. An Applicant can dynamically manage their 
application process, as well as, use automated job search services provided by RBAS. 
The Employer external systems have the capability to actively manage advertisements, 
and leverage candidate search tools. The Recruiter external systems are provided with a 
robust set of billet and candidate search tools that will expedite the hiring process. 
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Figure 34. RBAS Context Data Flow Diagram 
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The M.O.L. module represents Marine Corps legacy systems that will provide 
security services, as well as, data conduits to the RBAS system. The Monitor module will 
provide a Marine with a robust set of tools to aggressively manage their careers in 
concert with a Marine Corps monitor. 

C. FUNCTIONAL DECOMPOSITION DIAGRAMS 

Now that the overall scope has been defined and is understood, the next process 
model built was the Functional Decomposition Diagram. This model expands the “black 
box” that was depicted in the CDFD into a construct composed of its sub-systems which 
describe the proposed system in detail. Each sub-system has at a minimum of two child 
processes or modules [2]. The “children” of each sub-system provide the stakeholder 
with a comprehensive view of the different components or processes required of each the 
sub-systems. Within each child module the model becomes even more granular as each 
module is further broken down into specific processes or functionalities required for that 
specific child module to accomplish its designed functionality. Each of these “process or 
functionalities” was identified during the requirements analysis and they are defined in 
detail in use cases and event diagrams. A list of the use case glossary can be found in 
Appendix A, and the actual use cases themselves are presented in Appendices B through 
E. The four distinct sub-systems discussed in the CDED section will now be expanded 
upon. We will elaborate on the Employer Sub-System first, followed by the Candidate 
Sub-System, the Recruiter Sub-System and concluding with the Management Sub- 
System. 

I. Employer Functional Decomposition Diagram 

The Employer Eunctional Decomposition Diagram (EEDD), depicted in Eigure 
35, contains four children modules: Process Advertisements, Generate Managerial 
Reports, Target Potential Candidates and Manage Web Portal Settings. 

The Process Advertisement module contains eleven specific use cases which are 

presented in Appendix E. This module focuses on the manual and automated 

management of advertisements within the system. Within this module an employer has 

the ability to manually create, review, update and delete any advertisement. The RBAS 
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system will also automatically post and delete billets when they meet prescribed set of 
business criteria. To ensure that the billets generated automatically by the RBAS system 
are viable, the employer responsible for billet management will be provided a two week 
window from the inception of the automatically generated billets to review and approve 
the advertisements. If the employer is negligent in this responsibility and fails to approve 
or disapprove the billet within the two week window, the billets will be posted without 
the employer’s approval. This module also provides the employer with ability to manage 
the applicant pool for specific advertisements. This includes providing the ability to 
review the candidate pool, hire a candidate, reject a candidate, manage leads, as well as, 
communicate with entire applicant pool. 

The Generate Managerial Reports module will provide the employer with ability 
to generate a user defined report, advertisement history report, an advertisement details 
report, an advertisement response report and a billet expiry report. The billet expiry 
report is generated automatically and will be driven by temporal events at 30, 14, 7 and - 
14 days of the expiration date of the advertisement. 

The Target Potential Applicants module allows the employer to create, review, update 
and delete subscriptions that actively search for potential candidates. These subscriptions 
are an automated service that provides the user with the matching results of employment 
queries that are applied continuously against the RBAS data repository. These services 
are voluntary and must be signed up for by the candidate. This module also allows the 
employer to manually search for a specific candidate, as well as, contact them. 

The Manage Web-Portal module allows an employer to create, review, update and 
delete an employer’s personal web portal content. This allows the employer to 
dynamically change their environment to suit their needs and desires. This customizable 
interface would allow them to subscribe to Really Simple Syndication (RSS) broadcasts 
which include blog entries, news headlines, and podcasts in a standardized format. They 
will also be able to modify their background, install web widgets and view results of 
RBAS subscription notifications. 
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2. Candidate Functional Decomposition Diagram 

The Candidate Functional Decomposition Diagram (CFDD) is depicted in Figure 
36 and contains three children modules: Manage Personal Information, Apply for Vacant 
Positions and Employment Search Services modules. 

The Manage Personal Information module contains eleven use cases, which are 
presented in Appendix B, and it focuses on the candidate’s career management tools. 
Within this module the candidate is allowed to create, review, update and delete personal 
information that is contained in their Reserve Qualification Summary. This information 
that is modifiable is limited to the candidate’s employment history and their personal 
comments, because the rest of the data is autopopulated from Marine Corps Enterprise 
systems. If the candidate discovers an error within the autopopulated data he or she will 
have to utilize official Marine Corps channels to get it updated (S-1 or MOE). This 
module provides the candidate with the ability to create, review, update and delete their 
personal web-portal settings. This module also allows them to participate in community 
events such as blogs, webinars and other web driven resources that the candidate may 
desire to use. External Marine Corps services and the candidate’s ability to manage 
employment leads also reside in this module. 

The Apply for Vacant Position module allows a candidate to create, review, 
update and delete applications that they submitted. The candidate can also review their 
application history, the application pool for an active advertisement, contact the employer 
of an active advertisement, as well as, manually search for future vacant billets. 

The Employment Search Services allows a candidate to create, review, update and 
delete employment search subscriptions. These subscriptions are an automated service 
that provides the user with the matching results of employment queries that are applied 
continuously against the RBAS data repository. These services are voluntary and must 
be signed up for by the candidate. 
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Figure 36. Candidate Event Decomposition Diagram 


3. Recruiter Functional Decomposition Diagram 

The Recruiter Functional Decomposition Diagram (REDD) is depicted in Figure 
37 and contains three children modules: Utilize Candidate Recruitment Services, Manage 
Web Portal Settings, and Recruitment Management Tools. 
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The Utilize Candidate Recruitment Module contains seven use cases which are 
included in Appendix C. This module provides the recruiter with the ability to create, 
review, update and delete candidate search and billet search subscription services. These 
subscriptions are an automated service that provides the user with the matching results of 
candidate and employment queries that are applied continuously against the RBAS data 
repository. These services are voluntary and must be signed up for by the recruiter. This 
module also provides the recruiter with the ability to manually search for billets and 
candidates as well. Additionally, this module also provides the recruiter with resources 
necessary to run and manage community events. This includes services such as webinars, 
blogs and instant messaging. 

The Manage Web Portal allows the Recruiter to create, review, update and delete 
the Recruiter’s personal web-portal settings. This allows the recruiter to dynamically 
change their environment to suit their needs and desires. This customizable interface 
would allow them to subscribe to Really Simple Syndication (RSS) broadcasts which 
include blog entries, news headlines, and podcasts in a standardized format. They will 
also be able to modify their background, install web widgets and view results of RBAS 
subscription notifications. 

The Recruiter Management Tools module provides the Recruiter with the ability 
to generate ad hoc reports, manning reports, as well as, the ability to manage the leads 
generated by candidates and employers. This will provide the recruiter with a robust set 
of data that can be examined for trends and assist the recruiter in meeting his or her 
assigned mission. 
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Figure 37. Recruiter Event Decomposition Diagram 
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4. Management Functional Decomposition Diagram 

The Management Functional Decomposition Diagram (MFDD) is depicted in 
Figure 38 and contains four children modules: Manage Reserve Billet Advertisement 
System, Manage User Roles, Generate Managerial Reports and Manage Administrative 
Web Portal. 

The Manage Reserve Billet Advertisement System includes six use cases in 
Appendix D that focus the automated functionality and the interaction with Marine Corps 
Enterprise legacy systems. Specifically, this module addresses the automated population 
of the candidate and MOS tables of the database from the MCTFS and TFSMS systems. 
The module also provides the Manager with the ability to manage trouble calls, verify 
user’s credentials, as well as, perform limited maintenance to the system. The 
maintenance that the Manager can perform is limited to items that do not affect the 
normalization of the database. 

The Manage User Roles module allows the Manager to create, review, update and 
delete system user rights and privileges. Through this module the manager will assign 
users rights and responsibilities. This module will also allow managers to assign the 
privileges and capabilities of the different access roles within the system. 

The Generate Managerial Reports module allows the Manager to create ad hoc 
reports, user overview reports, system usage reports and a detailed user report. These 
managerial reports will allow the manager to monitor access and understand the different 
use patterns of users and groups. 

The Manage Administrative Web Portal module provides the Manager with the 
tools necessary to create, review, update and delete the Manager’s personal web-portal 
settings. This allows the manager to dynamically change their environment to suit their 
needs and desires. This customizable interface would allow them to subscribe to Really 
Simple Syndication (RSS) broadcasts which include blog entries, news headlines, and 
podcasts in a standardized format. They will also be able to modify their background, 
install web widgets and view results of RBAS subscription notifications. 
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Figure 38. Management Event Decomposition Diagram 
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D. SYSTEM DIAGRAMS 


The final step of our methodology is to stake the building blocks, the event 
diagrams, and construct the sub-system diagrams. These constructs provide the 
stakeholders with a complete picture on how all of the different events will work 
together. In this case, due the size of the system, we chose to construct sub-system vice a 
complete system. A complete system diagram would have detracted from the usefulness 
of the model. Each of the models is presented immediately following this introduction. 

The first model, depicted in Figure 39, is the Management Sub-System model. It 
clearly shows that this sub-system is geared towards the management of the users of the 
system, as well as, the functionality of the system. The second model, depicted in Figure 
40, is the Candidate Sub-System. This sub-system provides the candidate with a robust 
set of tools to actively manage their career. The third model, depicted in Figure 41, is the 
Employer Sub-System. This sub-system focuses on providing the employers the ability to 
not only advertise a vacant billet, but it also provides them with a proactive set of 
resources that they can use to search for candidates. The final model, depicted in Figure 
42, is the Recruiter Sub-System model. This sub-system provides the recruiter with 
dynamic capabilities that they require to actively pursue candidates. 
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Management Sub-System Diagram 
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Figure 39. Management Subsystem Diagram 
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Candidate Sub-System Diagram 
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Figure 40. Candidate Sub-System Diagram 
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Recruiter Sub-System Diagram 
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Figure 42. Recruiter Sub-System Diagram 
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V. PROPOSED SYSTEM ARCHITECTURE EOR NEXT 
GENERATION MARINE CORPS BILLET ADVERTISEMENT 

SYSTEM 

The previous chapter identified and defined the requirements for the next Marine 
Corps Reserve billet advertisement system. This chapter expands upon requirement 
definition by presenting a generic architecture in which the Marine Corps will be able to 
build their new system. 

To achieve that objective, this chapter is organized in the following manner: The 
Proposed Architectural Vision and Methodology section provides the readers with the big 
picture, examines the benefits and costs associated with the architectural design and 
concludes with the methodology used to for the development of the system’s generic 
architecture. The Proposed Prototype Architecture section presents our generic high-level 
architecture. The Quality Attribute Tree section presents readers with the metrics that will 
be used to measure the effectiveness of the proposed architecture. The Proposed System 
section will build an instance of a specific system using the generic architecture. Next, 
the Architecture Evaluation Section will use the quality attributes to gauge the 
effectiveness of the proposed system. Finally, the Risk Management Section will address 
the most significant risks to the proposed generic architecture. 

A. PROPOSED ARCHITECTURAL VISION AND METHODOLOGY 

1. Architectural Topology Selection 

During the analysis of the results of the literature review and requirements 
analysis viable architectural patterns, frameworks and components were discovered and 
incorporated into the future system design. Specifically, it was determined that all of the 
systems analyzed were built from a variation of a hub and spoke architecture and that 
they used the Internet as the primary medium to connect the system to its users. 

2. The Vision 

From these findings, we were able to develop a Software Product Fine (SPF) with 

a specified Product Fine Architecture (PFA) that addresses the needs of the future Marine 
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Corps billet advertisement system. This SPL not only helps the Marine Corps, but it will 
also extend to any component of the DoD that needs to build a dynamic billet 
advertisement system. According to Ian Gorton’s book Essential Software Architecture 
an SPL is a collection of related products developed by combining core assets with 
product-specific assets that vary the functionality of the core assets, and a PLA is a reuse- 
oriented architecture for the core assets of the SPL [26]. This reusable solution would 
address many other problems within the DoD and not just that of the Marine Corps 
Reserve. For instance, the SPL would not only solve the Marine Corps quandary on how 
to build an adequate billet advertisement system, it also addresses similar problems 
experienced by other components of DoD that need to advertise and fill billets of any 
type. A great example of this would be the military school houses and training centers 
which are driven by filling and managing billets within their respective commands. Both 
of these commands could use the SPL to quickly build a dynamic billet advertisement 
system at a much lower cost than building it autonomously. The potential for this type of 
SPL for the DoD is boundless as the majority of all military personnel management and 
training systems are driven by billets that need to be filled and advertised. 

3. Software Product Line Benefits 

There are many benefits to leveraging an SPL. First and foremost it would save 
the DoD significant amounts of money, and second it would reduce the manpower and 
efforts required to build a new products because of the reuse of software products [4]. 
Specifically, an SPL will save DoD money in the building process because the design of 
each new specialized variant requires less time and money to implement the new asset. 
This would reduce costs to the DoD considerably. An SPL would also save money due to 
the reduced costs of maintaining the systems [4]. For instance, if a piece of software 
contained in the SPL was upgraded, the cost of the upgrade is distributed over all users of 
the SPL. In its current configuration of isolated and stovepipe systems, the DoD has to 
pay for the same type of upgrade for each system individually rather than distributing the 
cost across all of the systems. This is a significant expenditure. These points make it 
blatantly obvious that the DoD is incurring a lot of unnecessary expenses that are 
mitigated by using an SPL. 
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Leveraging an SPL would not only save the DoD money, it would also free up 
manpower and resources by reusing a product. An SPL would reduce manpower 
requirements because it eliminates numerous duplicated managerial and maintenance 
efforts that are associated with stovepipe systems. For example, currently each agency 
within the DoD manages the life cycle of each of its different billet advertisement 
systems. This correlates to many redundant and duplicated efforts by a large body of 
managers. An SPL also reduces maintenance requirements because of the common 
architecture being leveraged. This reduction would be apparent if the DoD converted all 
of their billet advertisement systems to an SPL built on a common PLA, because the life- 
cycle management becomes considerably easier and less manpower intensive because the 
core of each system is now the same. 

4. Concerns and Issues 

These arguments make it easy to see why utilization of an SPL is beneficial, but 
there are some concerns for building a SPL. For the remainder of this section we briefly 
discuss a few of the high level concerns, followed by a description of how the proposed 
system is tested. As with any SPL an architect is concerned about defining the scope and 
the market of a system. In this case, each of the systems that we reviewed all had similar 
scope, and the market of the new SPL is simple - the DoD. We are not trying to trivialize 
these two problem concerns (scope and market), but because of the unique environment 
in which this SPL is being built they are much easier to get a handle on than in a 
commercial environment. Gorton identified three other factors that may act as “barriers” 
to an organization adopting an SPL, and we consider these briefly. These areas are: 
change of control issues, the definition of core attributes and the design of the PLA [4]. 

Change of control issues spawn from the stakeholder’s reluctance or fear to 
relinquish their power and control over their systems. For example, within DoD every 
service wants control over the purse strings of their IT systems, because this provides 
them with the ability to manage and shape the system as they see fit. This thought process 
is fractured because it leads to the services duplicating their efforts and poorly designed 
systems. This is evident in DoD as each service has built its own billet advertisement 
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system, all of these systems are severely flawed and eaeh serviee pays more than it needs 
to maintain its system beeause eaeh one ineurs all the eosts itself. Stakeholder interviews 
revealed that eaeh of the serviees understand that its system is ineomplete and eaeh 
identified the need for a more eomplete system, but even with this omission none of the 
serviees want to relinquish eontrol by building a joint system billet advertisement system. 
The next problem identified by Gorton is how to determine what the eore attributes for 
the proposed SPL are. In this ease a thorough review of requirements doeuments and 
stakeholder interviews eaptured the majority of these attributes. The initial results were 
presented to the stakeholders for review and approval whieh they aeknowledged. The last 
problem diseussed by Gorton was system design. The design will foeus on the eore 
attributes identified through requirements analysis. Stakeholder interviews also identified 
all of the variations required by the different produets. Understanding this “variation” is 
important when designing a PLA, beeause the design of the PLA must ensure that these 
varianees are eompatible with the eore attributes. 

5. Strategic Methodology - The Way Forward 

To prove the eoneept that a SPL is sound and that the vision has merit, we are 
going to apply this vision to our original problem domain of advertising and filling billets 
for the Marine Corps Reserve. The system built from the proposed generie arehiteeture 
will be validated and tested against stakeholder defined metries, quality attributes, to 
measure the effeetiveness of the proposed arehiteeture. This proeess is depieted in Figure 
43. 

The generie arehiteeture was designed using a hybrid version of the FAST and 
ATAM methodologies to perform our analysis. In this ehapter we used steps four through 
eight of the ATAM methodology, a brief deseription of eaeh follows. 

Step four of the ATAM methodology expands upon step three by deseribing the 
generie eomponents, the topology and the framework in detail. Step five generates the 
Quality Attribute Utility Tree. The Quality Attribute Utility Tree identifies and prioritizes 
the system’s most important quality attributes [3]. The output of this tree generates 
speeifie quality attributes in the form of seenarios. Step six through eight leverage the 
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scenarios generated by the utility tree. The scenarios are used to rank and analyze the 
different quality attributes, which allows the architect to focus on the final architecture 
and the construction of the product. 


6. 

Problem 
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-y 

5. Vision 



Each component in the proposed architecture 
will correlate to a generic component in the 
generic high-level architecture 
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Quality Attributes 
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The proposed 
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Figure 43. Strategic Overview Methodology 
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B. PROPOSED PROTOTYPE ARCHITECTURE 


1. Generic Product Line Architecture 

Our first step was to build a generic PLA. Figure 44 contains a depiction of this 
high-level generic architecture we built. This architecture captures the essence of the 
framework required for any billet advertisement system utilized by any DoD component. 
The natural layout of this high-level architecture correlates to a hub-and-spoke 
architecture which maximizes the connectivity between the front-end users and the back- 





Figure 44. Generic High Level Architecture 


end legacy systems by decoupling the systems. Decoupling the systems allows the 
different systems to continue to utilize their programming language and data structures, 
because they send their output in its natural form to the centralized hub which contains 
definition and transformation logic that is used to convert the messages into a common 
format [3]. 
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2. Billet Advertisement System Module (BASM) 

The “hub” of this architecture is the Billet Advertisement System Module 
(BASM), because this module connects all of the different resources and modules and 
drives the entire process flow. The BASM will automate the job vacancy advertisement 
process by drawing and comparing information that is contained in the different 
personnel and planning information warehouses. BASM will also provide all of the 
management services, ad hoc management report generation capabilities and web 
services for the system. This module will also enforce all expiry dates to minimize the 
amount of dirty data that is stored in the data repositories. 

The BASM acts as the “hub” all other modules are dependent upon it, therefore, 
the reliability and performance of the BASM is paramount to the success of the system. 
That being said, the BASM’s primary quality attributes are system availability and 
system throughput. To meet this requirement the BASM must be available to its users 
greater than 99 percent of the time, and it will handle, at a minimum, 100 billet query 
messages per second during peak usage periods. The BASM will incorporate robust and 
redundant mirror sites that will share the transaction load, as well as, pick up the load if 
one of the systems should fail to ensure that further ensure that the availability quality 
attribute is met. The requirements discovery also identified that the BASM must be 
modifiable due to the constant evolution of military organizations. To address this 
requirement the BASM will provide system administrators with the ability to make 
changes to the aesthetics of the system, as well as, the ability to change nomenclature. 
This will allow the site to remain fresh and accurate without compromising the integrity 
of the system. The BASM will also provide the user with a robust set of career and 
management tools. These tools will allow the reservist to actively manage their career, 
and they will provide system managers and employers with ad hoc report capabilities, as 
well as, administrative tools. Connected to the hub in this star topology are four core 
modules: the Recruiter Module (RM), the Employment Module (EM), the Candidate 
Module (CM) and the Data Module (DM). 
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3. Recruiter Module (RM) 

The RM provides job recruiters with a portal in which they can tap the resources 
of the BASM, receive direction from the various employers using the system, as well as, 
receive leads generated by the interaction of applicants with the system. The RM will use 
HTTP/HTTPS and FTP/FTPS via the Internet as its primary means of passing 
information to and from the BASM. The RM’s primary quality attributes are 
accessibility and security. Due to the mobile nature of a “recruiter” accessibility to the 
system is paramount. Therefore, the RM will be accessible via several access methods, 
including, but not limited to, mobile devices such as PDAs, cell phones and laptops. In 
order to meet this quality attribute the architecture will handle messages transmitted over 
different channels such as the Internet using a SOAP message protocol. The RM will also 
provide a large tool bag of web tools such as blogs, email, cellular technologies and 
instant messaging. These “tools” will maximize the connectivity and accessibility with 
potential applicants. Because of the number of ways a user connects to the system, 
security is a significant concern. Firewalls, virus-protection and identity management will 
be built into the architecture to mitigate much of the risk posed by these mobile users. 

4. Employer Module (EM) 

The EM provides the different employers with a portal in which they can 
advertise job vacancies, actively manage the hiring process and search for potential 
candidates of interest. This portal will also provide a conduit in which they can actively 
drive the recruiters’ efforts by prioritizing the job postings dynamically. The EM’s 
primary quality attributes are usability and authorization. The architecture is designed to 
make the process as simple as possible for Employers, i.e. more usable. Eor example, an 
employer will receive real-time updates to changes that affect the candidate pool, such as 
when applicants withdraw their applications from the queue. This will allow employers to 
make more informed decisions during the hiring process. Employers can also contact 
potential applicants via email or instant messaging in order to request additional 
information. Authorization must be aggressively addressed, because of the employer’s 
access to personal and professional information of candidates. To ensure this quality 
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attribute is meet system administrators will grant and manage employer’s access to the 
system. Beyond usability and authorization, because the employers are accessing 
individuals’ personal data, security is critical. Therefore, when private data is accessed, 
the system will use encrypted SOAP messages over HTTPS or FTPS. If the size of 
SOAP messages becomes an issue due to system constraints, other more compact binary 
message formats such as CORBA, GIOP, or ICE will be utilized. Also, transactional 
integrity must also be guaranteed; to do this, the system will lock the job management 
resources until it receives a positive response from the BASM that acknowledges 
successful completion of the transaction. 

5. Candidate Module (CM) 

The CM provides a portal in which all applicants are able to search and apply for 
vacant positions advertised by their DoD force. The AM’s primary quality attributes are 
usability and security. Specifically, the system’s usability is enhanced by: First, 
applicants can monitor the state of a current application, view their previous work history 
or modify or delete any application that has not already been reviewed by the potential 
employer. Second, applicants are able to leverage dynamic resources in which they can 
manage their personal and professional information. Third, applicants can join a 
“community” where they are able to discuss matters which interest them with other 
members in order to induce networking and a sense of belonging. Again, because the 
sensitivity of the information being submitted by the applicant, the importance of security 
is paramount. Therefore, just as in the EM module, measures such as using encrypted 
SOAP messaging over HTTPS or FTPS are built into the system to ensure the safety of 
private information being submitted by the user. And also like the EM, transactional 
integrity must be guaranteed in the CM; to do this, the system will lock the application 
resources until it receives a positive response from the BASM that acknowledges 
successful completion of the transaction. 

C. QUALITY ATTRIBUTE UTILITY TREE 

Following the specification of the high-level architecture, a detailed stakeholder 
analysis was conducted to determine the “wish lists” for the system. This analysis 

81 



included stakeholder interviews, literature review, as well as, a thorough analysis of the 
current iteration of RDOL. These efforts led to the definition of the required quality 
attributes of the system, which were inserted into “a utility tree” or “a quality attribute 
tree,” (Figures 45 through 47) to make it easy to understand and digest. This step is 
particularly important, because quality attribute utility trees focus efforts on the aspects 
of architecture that are critical to the success of the system [26]. The developed tree, 
while not all inclusive, does just that as it includes the attributes that were deemed by the 
stakeholders of the system as most important. They include the following critical 
attributes: timeliness, automation, modifiability, integration, security, usability and 
availability. 

The following is a brief description of the high-level quality attributes that were 
defined by the stakeholders. The timeliness attribute defines how the age of an 
advertisement affects the viability of the data. The automation attribute addresses how 
data and when data is transferred to the advertisement system, what data sources are 
utilized and how the information is coalesced and processed. The modifiability attribute 
defines how the system is configured, how it will respond to growth and how it will scale 
to increased use. 
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Figure 45. Quality Attribute Tree (Top Section) 


The integration attribute defines the interoperability of the system with other 
systems and how it will communicate with them. The security attributes identifies how 
the system will authenticate and authorize resources to its users. It also defines the 
requirements on how the system will guarantee the integrity of the data being transmitted 
between systems. 
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Figure 46. Quality Attribute Tree (Middle Section) 

The usability attribute defines what tools are available to reservists and managers, 
and it defines how data is structured as the user inputs information into forms. Finally, 
the availability attribute will define aspirations for uptime and accessibility, which will 
ultimately affect the hardware and redundancy qualities of the system. 
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Figure 47. Quality Attribute Tree (Bottom Section) 


D. PROPOSED SYSTEM 

After analyzing the required quality attributes and reviewing the generic high- 
level architecture, the next step in our process was to build a specialized instance of this 
generic architecture. Every component within this specific system correlates directly to a 
generic component within the PEA. It was determined that leveraging the robustness of 
commercial components by plugging them into our generic architecture provided the best 
solution for the Marine Corps. This decision was made because the billet advertisement 
systems currently deployed by the DoD failed to meet the litmus test due to poor design, 
lack of documentation and inadequate management. Eor example, the JOAPPEY system 
deployed by the Naval Reserve was built iteratively from a small Excel worksheet. As the 
system grew, system administrators failed to document the changes that were made to the 
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system which led to significant compatibility issues, as well as, major scaling issues. This 
“no plan” type build has led not only to technical issues, but also led to significant 
maintenance costs. This type of problem was indicative of every DoD system that we 
analyzed. 

Therefore, it was concluded that building a hybrid system by integrating 
Monster.com’s commercial architecture within the generic architecture provided the most 
complete and viable solution. This approach prevents the DoD from “reinventing the 
wheel,” because it uses existing and proven commercial technologies. It also minimizes 
life-cycle maintenance costs; because the primary billet search system is already mature 
and has been optimized. In addition, it affords the DoD with the best opportunity to get a 
system up and running the quickest. Figure 48 presents a high-level view of the hybrid 
architecture that we propose that the Marine Corps adopt and deploy. This system was 
built from the framework of the generic architecture proposed earlier in this paper; that 
being said, we will emphasize this point by breaking each component down and tying it 
back to the corresponding component in the generic architecture. The “hub” of the 
generic architecture is the BASM. With this proposed instantiation the functionality and 
responsibilities of the BASM is distributed over five modules: the Application Module, 
the Monster Business Gateway, Marine Corps Recruitment System (MCRS), Marine 
Corps Employer Agency System (MCEAS) and the Marine Corps Reserve Management 
System. We breakdown the system based on these three components. 
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Figure 48. High-Level View of Proposed System 


1. Application Module 

The Application Module captures all the quality attributes defined for the AM 
module in the generic architecture, but it also inherits the community socialization tools 
that were originally assigned to the BASM. In fact, the Applicant Module is where the 
primary front-end users interact with the system, and it is completely contained within the 
domain of the Monster.com portion of the system. The reason for this is simple: Monster 
knows what it is doing on the front-end. Monster, in its current configuration, has 17 
unique job search networks and 40 international sites which encompass both commercial 
and academic institution portals [27]. This congregation of resources has created an 
impressive data warehouse of potential candidates, in fact, as of June 2007, Monster and 
its subsidiaries housed over 80 million unique job seeker resumes and 40,000 more are 
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added each day [28]. This makes it easy to surmise that they are able to handle the 
increased volume of consumers that Marine Corps Reservists will introduce to their 
system. 



Figure 49. Monster Business Gateway Component View 


2. Monster Business Gateway (BGW) 

The Monster Business Gateway (BGW), depicted in Figure 49, is the next module 
analyzed. The BGW will act as the sole interface and the hub between Monster.com 
resources and the Marine Corps systems. Therefore, this component takes much of the 
messaging responsibilities that were delineated for the BASM presented in the generic 
high-level architecture. Specifically, it will pass all information between the different 
spokes of the hub and spoke architecture. Messages to and from the BGW will support 
SOAP XML requests over HTTP/HTTPS or FTP/FTPS. The SOAP header will contain a 
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time stamp, a unique message ID and an authentieation tieket [20]. The eombination of 
HTTPS/FTPS protoeols and the SOAP header eontents address the seeurity quality 
attribute requirements. Information transferred internally within Monster is distributed by 
applieation servers whieh will disseminate the data to the appropriate eomponent within 
Monster. The BGW has multiple mirror sites and Monster guarantees over 99 pereent 
availability for this resource. The BGW can also handle over 1000 transactions per 
second [20]. Both of these results exceed the accessibility and throughput quality 
attribute requirements that were defined in the BASM portion of the generic architecture. 
All transaction requests submitted or received via the BGW are positively acknowledged 
near real-time depending on the size of the file being transferred. 



Figure 50. Marine Corps Reserve Management System Component View 
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3. Marine Corps Reserve Management System (MCRMS) 

Figure 50 depicts the Marine Corps Reserve Management System (MCRMS), and 
it contains the last of the distributed attributes of the BASM from the generic high-level 
architecture. Specifically, this module will provide the automation and management tools 
that were originally the responsibility of the BASM. This component is built using a three 
tier architecture that is housed at Headquarters Marine Corps with a mirrored sight 
maintained at MARFORRES in New Orleans. The top layer, the Web Services Tier, is 
located within the Demilitarized Zone (DMZ) of the Marine Corps domain. Its purpose is 
to unwrap or wrap data in an appropriate SOAP wrapper and transmit it to the 
Application tier or the BGW for processing. The bottom layer, the Marine Corps 
Enterprise Data Warehouse Tier, is currently comprised of numerous legacy systems that 
operate autonomously. This layer is conceptually made of up of the Marine Corps Total 
Eorce System (MCTES) and Total Eorce Manpower Models Reengineering System 
(TEMRS). MCTES, the Marine Corps personnel system, houses all of the personal data 
and assignment history of current and past Marine Corps personnel. TEMRS, the Marine 
Corps manpower modeling system, houses all of the Marine Corps present and future 
manning models. The top and bottom tiers are connected to the application layer of the 
MCRMS via the Marine Corps secure EAN. 

The Application Tier, the middle component, will contain a Billet Calculation 
module, a Resume Information module and a Reservist Management module. The Billet 
Calculation model will query current Table of Organization data for a specific Reporting 
Unit Code (RUC) from TEMRS, and it will query for current Marines on hand for the 
same RUC. The application will then determine which billets are vacant for that RUC by 
looking for disparities between the two sets of data. This functionality meets the 
requirement defined by the timeliness quality attribute defined in the Quality Attribute 
Tree. The Resume Information Module will query data from MCTES to auto-populate 
resume fields. This attribute meets the requirement defined by Billet Management quality 
attribute defined in the Quality Attribute Tree. The Reservist Management Module will 
allow authorized users to make modifications to the site, create on demand reports and 
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assign user roles. This application is provided by Monster. The results of any queries are 
transmitted to the Monster site via the Web Services Tier which will send it to the BGW. 



Figure 51. Marine Corps Recruitment Systems Component View 


4. Marine Corps Recruitment System (MCRS) 

Figure 51 depicts the Marine Corps Recruitment System (MCRS) which provides 
the Recruiters with a robust set of tools in which they can leverage leads generated by 
reservists that visit the Monster website. It correlates directly to the Recruiter Module of 
the generic high-level architecture. The MCRS is comprised of a three tier architecture 
that is housed at Headquarters Marine Corps with a mirror site at the West Coast 
Regional Recruiting Office. The top layer, the Web Services Tier, resides in the DMZ on 
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the Marines domain the same as the MCRMS system. The recruiting data warehouse is 
comprised of a proprietary data warehouse that is maintained by Marine Corps Recruiting 
Command. 

Due to the breadth and dispersed nature of recruiters, this node is accessible 
remotely via VPN or remote access point via any peripheral device that has access to the 
Internet and has encryption capabilities. That application tier will house Monster software 
that will allow them to remotely logon to the site, use management tools and leverage 
recruitment tools. This Monster application will also facilitate the broadcasting of leads 
to recruiters near real-time. Specifically, when a reservist expresses interest in a billet, a 
lead is generated by Monster and transmitted to the Recruiters automatically. “Interest” is 
defined as anyone who submits a resume, or anyone who submits an application or 
anyone who request additional information. This is relayed via the gateway to the web 
server and finally to the application server which then disseminates the information to the 
various devices held by the recruiter closest to the prospect. Because of this, the module 
meets the accessibility quality attribute that was defined by the generic architecture and 
the quality attribute tree. Moreover, this module meets the security quality attribute 
because all information transmitted between the remote user and the MCRS is sent via 
HTTPS and is encrypted. Users also have the ability to use VPN services to further 
secure their communication. 
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Figure 52. Marine Corps Employer Agency Systems Component View 


5. Marine Corps Employer Agency System (MCEAS) 

Figure 52 depicts the Marine Corps Employer Agency System (MCEAS). This 
node provides employers with the tools and resources necessary to advertise vacant 
billets, as well as, search for potential candidates. It correlates directly with Employer 
Module from the generic high-level architecture, and it meets all the quality attributes 
defined by the Employer Module. This node of the system is also built upon a three-tier 
architecture. The top layer resides in the DMZ the same as the previous two systems. The 
bottom tier is comprised of numerous data warehouses that currently reside in the 
different stove pipe systems that exist within the Marine Corps. No queries are applied 
against these data sources, but the connectivity is established for future application 
possibilities. Monster will provide the application that allows employers access to the 
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new system. This application will allow them to build and manage advertisements, track 
and monitor response and review resumes. It will tie back to the system via the BGW. 

E. ARCHITECTURE EVALUATION 

Using the Quality Attributes (QA) identified earlier, we evaluate the proposed 
system that was built using the generic architecture. QAs represent the metric, as defined 
by the stakeholders that are used to measure the viability of the proposed architecture. 
QAs are inserted into a hierarchical tree, and each branch of the tree represents a QA. The 
leaves of each QA branch represent scenarios that are used to qualify the desired level, to 
operationalize the meaning of the quality in practical contexts, and to evaluate whether 
the architecture meets the needs defined. However, we will only address four scenarios, 
tied to particular aspects of the architecture due to broad scope of the project and limited 
manpower. 

The first scenario ensures that a Manager can make changes to the system as 
nomenclature and requirements change within the DoD. The military undergoes 
continuous change, therefore its systems must adapt with them or they will become 
antiquated well before their project useful life. The second scenario ensures that the jobs 
posted within the site are viable and accurate. In the past, many of DoD systems did not 
have any business rules in place to ensure that the data being displayed was within 
periodicity or that the information being displayed was correct. The third scenario tests 
the connectivity between the new system and the legacy systems within the Marine 
Corps. This is significant, because all of the data repositories that our drawn from all are 
built from older technologies. The fourth scenario ensures that reservists can actually 
search for prospective employment. If this function doesn’t work, the system doesn’t 
work. 
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Scenario #: 

1 

Scenario: 

Assigned management personnel (military or civilian) with level one computer skills, 

inputs new broadcast message, or modifies webpage aesthetics (front-end). 

Attribute(s): 

Modifiability 

Environment: 

Normal Operating Conditions. 

Stimulus: 

System manager desires to update the broadcast message on the site’s homepage to 

disseminate information to all current users without the use of spam. 

Response: 

A broadcast message is sent to all applicable recipients. 

Architectural 

decisions: 

The key architectural decision made was the manner in which broadcasts are 

transmitted to the desired audience. In this instance, messages are transmitted via the 

BGW and posted in an ALERT section of the user’s homepage for review. 

Reasoning: 

Stakeholders expressed the desire for a Manager to log onto the system and broadcast 

informational messages without the help an IT professional. They also expressed a 

desire to limit the amount of information that was transmitted via email. Therefore 

ALERT messaging using SOAP was selected as the means to broadcast messages to 

users of the system. 

Diagram: 

(verbal description) 

In this scenario, the RDOL manager begins by successfully logging into RDOL with 

the appropriate privileges to make changes. He or she would then enter the reserve 

management module and creates a message. Once the message is complete and the 

user hits “post message.” it is wrapped in a SOAP wrapper, passed to the web services 

layer, and then transmitted via HTTPS to Monster via the Business Gateway. The 

BGW submits it to the appropriate application within the monster domain. Upon 

successful submission, a positive response is presented to the user via email/popup. 

Diagram: 

(pictorial presentation) 
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Analysis: 


As this system is largely unchanged since its inception in 2001, many stakeholders 
wanted minor adjustments to the website front end (CSS modifications) or simply the 
manner in which the page was laid out (tabs, menu style). The current iteration of 
RDOL requires thousands of dollars and numerous man hours to make even the 
slightest change to the front end. 

This methodology addressed a very important concern identified by several 
stakeholders; therefore it meets the system configuration portion of the modifiability 
quality attribute identified in the generic architecture. 
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Scenario #: 

2 

Scenario: 

The system must automatically execute removal of advertised billet upon its expiration 

date. 

Attribute(s): 

Timeliness 

Environment: 

Normal operating conditions. 

Stimulus: 

Time triggered event. Daily the system will perform a query that determines which 

billets are about to expire, which have expired and which are greater than two weeks 

past their expiry date. 

Response: 

The system will respond in the following manner: 

1. It will notify recruiters and employers of all billets that are within two weeks 

of its expiration date. 

2. A follow-up notice is transmitted to both the recruiters and employers one 

week from the expiration date. 

3. At the expiration date the vacancy is locked and no one can apply for it, but it 

will remain posted on the site for an additional two weeks in order to serve as 

a recruiting tool. Employers are notified of billets that remain unfilled. 

4. Two weeks after the expiration date the vacancy are removed from the active 

site and archived. 

Architectural 

A daily temporal event triggers a SQL query of active data repository, and results are 

decisions: 

transmitted via notification process. 

Reasoning: 

Daily querying against the active data repository ensures that only viable, active billets 

are displayed for applicants conducting searches. It also minimizes the amount of false 

applications. It keeps the data clean. 

Daily querying also provides recruiters and employers with notifications to ensure that 

they understand the time constraints associated with vacant billets. 

This provides employers an opportunity to modify the billet if so desired, and it also 

provides recruiters with information that will allow them to correctly prioritize their 

efforts. 
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Diagram: 

(verbal description) 

Daily, at a time determined by the system manager, the system will query the active 

data repository. The results of the query are transmitted to the BGW. The BGW will 

then pass a SOAP message to the appropriate recipients. The recipients systems will 

then post the announcement in the ALERT section, as well as, generate an instant 

message or email to notify the concerned parties. 

Diagram: 

(pictorial presentation) 
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Analysis: 

This event ensures that the data being presented to candidates is accurate and timely. It 

will also assist the employers by providing them with warnings. These warnings will 

allow the employer to either change the expiry date or push the recruiters to fill the 

billet by raising its priority. Recruiters are provided with a notification in order to keep 

them focused on the most significant events. 

This event does generate email, which is not desirable, but the significance of the 

event overrides the desire to minimize spam therefore it is transmitted. 
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Scenario #: 

3 

Scenario: 

The system must automatically populate fields in RDOL from external sources 

(Operational Data Storage Enterprise (ODSE), Total Eorce Structure Management 

System (TESMS)) wherever possible. 

Attribute(s): 

Automation (specifically billet management in this scenario) 

Environment: 

Normal operating conditions. 

Stimulus: 

Temporal or physical events trigger this action. Specifically; 

1. The system will query billet data sources weekly to ensure that the 

information contained in the active billet repository is up to date. 

2. Any major manual updates to the Marine Corps billet structure or manning 

structure within the legacy systems (TESMS) will trigger this event. 

Response: 

When a trigger occurs the reserve management system will query the Marine Corps 

legacy systems. The results of the query are used to update the active data repository 

that the Monster.com site pulls data from. 

Architectural 

1. Applications housed in the middle tier will provide access to the different 

decisions: 

data repositories housed within the Marine Corps Enterprise system. This 

application will also transform the data retrieved into the proper format that is 

specified by this system’s business rules. 

2. The system will then compare on-hand Marines (ODSE data) versus the 

required Marines (TESMS data). Any disparities between on-hand Marines 

(actual) and Table of Organization billets (ideal) will create an advertisement 

from each vacancy that exists after comparing the two datasets. 

3. Query results are transmitted via ETPS from the Reserve Management 

System to the Monster.com system to ensure the safety and integrity of the 

data. 

Reasoning: 

This automation will alleviate much of the work that is currently done by hand. It will 

also ensure that the billets being advertised are current. 
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Diagram: 

(verbal description) 

When a trigger event occurs the system will query the legacy systems. The results 

from the query are processed, and vacant billets are identified. These results are 

converted into a SOAP message and transmitted via the BGW to the Monster system. 

These active data repositories are updated, and the new job vacancies are available for 

consumption by reservists. 

Diagram: 

(pictorial presentation) 
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System System 

Analysis: 

The ability to query data from two legacy applications is a significant improvement 

from the previous version of RDOL and is the key to alleviating dirty data and saving 

numerous man hours. This scenario also stresses the dependence of the “Automation” 

quality attribute on the “Integration” quality attribute. Because if the system cannot 

communicate and integrate the data received from the legacy systems the automation 

of the system will fail. This also makes it evident that the Billet Calculation Module 

that will query and transform information from the legacy systems plays a significant 

role in this process. If this module does not work properly the automation quality 

attribute is not met, therefore, before deployment of the system, this module must 

undergo significant testing and evaluation. 
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Scenario #: 

4 

Scenario: 

The system must allow reservists to search postings, modify resumes, and edit 

preferences. 

Attribute(s): 

Usability 

Environment: 

Normal operating conditions. 

Stimulus: 

1. A reservist queries the site for vacant positions of interest. 

2. A reservist chooses to view or modify his or her resume. 

3. A reservist changes their notification preferences within the system. 

Response: 

1. The Monster.com system will generate a query against the active data 

repository housed within Monster’s domain. 

2. The Monster.com will generate a query against the Marine Corps data 

repositories. The results of the query will auto-populate a member’s resume. 

3. The reservist will make changes directly to a “preference” table that the 

system uses as arguments for functions of the system. 

Architectural 

Auto-populating fields make it easier for the user to fill out resumes while eliminating 

decisions: 

the chance of inputting dirty data, and it also ensures that the reservists are updating 

their personal information. 

Reasoning: 

The following architectural decisions were made when creating this application: 

Viewing Vacant Positions 

1. All active job vacancies are housed in the active data repository. 

2. All functionality to query the active data repository are contained in the 

Monster.com system. 


Modifying Resume 

1. All personal information fields of the resume will populate automatically by 

the information contained in the Marine Corps data repositories 

(MCTFS/ODSE). 

2. Every transaction is logged and accounted for to ensure that every transaction 

is processed properly. 
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3. All personal data is transmitted via HTTPS or FTPS using a SSL. Each SOAP 
header will contain a ticket that will uniquely identify and verify a user and 
his/her privileges. 

4. Only certain fields are modifiable by the candidate. If a candidate identifies a 
field that needs correction, but is not modifiable, the user is directed to the 
resource that can modify it (MOL). 

Notification Preferences 

1. Preferences are stored in a table in the active data warehouse. 

2. Reservists will use an application to change the information contained within 
this warehouse. 


3. Business rules will limit a Manager can change. 


Diagram 1: 


Once a reservist is logged on to the system and his/her credentials are verified, the 


(verbal description) 


reservist will input their search criteria into the query application. The Query 


Application queries the active data repository and the results are displayed for the 


reservist. 


Diagram 1: 

(pictorial presentation) 




Query Active Data 

Application Repository 



Diagram 2: 

(verbal description) 


Once a reservist is logged on to the system and his/her credentials are verified, the 
reservist requests his or her resume. The system generates a query which is transmitted 
via the BGW to the Reserve Management System. The Reserve Management system 
queries the Marine Corps Enterprise data repositories and the results are sent back to 
the Monster system. The Monster system processes the information and uses it to 
populate the resume requested by the reservist. 


Diagram 2: 

(pictorial presentation) 
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Diagram 3: 


Once a reservist is logged on to the system and his/her credentials are verified, the 


(verbal description) 


reservist will input his/her search criteria into the query application. The Preference 


Application will provide a structure environment in which the reservist can directly 


update their preference information in the active data repository. 


Diagram 3: 

(pictorial presentation) 
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Analysis: 


The system responds well to the scenarios. The following were some vulnerabilities 
that were noted during the analysis: First, the preference application worked directly 
with table data which, if not done correctly, could negatively affect the normalization 
and the integrity of data being stored in the repository. Second, the auto-population of 
a resume will significantly limit which fields the reservist can update. Specifically it 
will limit them to updating recall information and address information. The Marine 
Corps will not allow a reservist to modify or update any professional or other personal 
attribute without coordinating it with the Marine Corps personnel office. This will 
significantly slow this process down, and could lead to resumes being submitted with 
incorrect data to circumvent this tedious and slow process. 


F. RISK MANAGEMENT STRATEGY 

As with any architecture, there are potential flaws associated with our proposed 
architecture. Our goal for this section is to minimize the risk that these “flaws” expose to 
our stakeholders. In that light, we examined our proposal from the top down, and 
identified any weak areas or potential threats to the proposed architecture. We then 
thoroughly analyzed each of these weakness, and attempted to determine the probability, 
analytically not qualitatively, that the event would occur, as well as, we attempted to 
prognosticate the scope of the damage to the system if the event occurred. We then used 
the results of the analysis to prioritize the different risks to the proposed architecture. 
Each of these risks are presented below in sequential order. 
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1. Single Point of Failure 

The BGW is a single point of failure, and represents the biggest threat to the 
system. The Internet has no business hours and the numerous users of RDOL are spread 
throughout the globe in many different time zones. With the BGW being a single point 
of failure, the cost of losing this middleware is compared to the requirements identified in 
the QA “availability” as defined by the stakeholders. As Gorton pointed out, 
“Replicating components is a tried and tested strategy for high availability. When a 
replicated component fails, the application can continue executing using replicas that are 
still functioning. This may lead to degraded performance while the failed component is 
down, but availability is not compromised [26].” 

Coupled with availability is the issue of recoverability. Recoverability is defined 
as the capability to reestablish the systems required performance levels and restore data 
that was interrupted during the outage/failure. In the case of RDOL, during a system 
outage, the only billets that could not be automatically recreated very quickly would be 
the Individual Augment (IA)/Active Duty Operational Support (ADOS) billets that were 
manually entered. A broadcast message could be sent following the outage notifying 
users that there was an outage and to validate all recent manually inputted billets. 
Component replication does ensure as close to 100% availability but comes at a 
significant cost. This cost would have to be weighed against a less complicated solution 
such as daily off-site backups of the active billet repository. 

Finally, mitigating the risk of the BGW acting as a single point of failure boils 
down to the amount of cost you are willing to incur. At one end of the spectrum you 
could have multiple, redundant, load balanced applications at separate sites that will 
process and transmit data in parallel (this can create its own set of problems with 
inconsistencies/ transactions). On the other end of the spectrum, you have the minimum 
of nightly off-site backups. It comes down to how much you are willing to spend to get 
the availability/recoverability that is desired. No solution is perfect; it comes down to 
risk versus gain. In this case, due to the nature of the proposed system we recommend 
that you minimize the costs of the system by conducting nightly backups. Monster.com 

has numerous mirror sites to protect the BGW, so the cost of the redundant systems need 
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not be incurred by the government, and the backing up the daily transactions would 
provide additional protection to the risk posed by using star topology. 

2. Unauthorized Access 

Due to the large number and dispersed access points to the system, unauthorized 
access to the system poses a significant threat to its users and the Marine Corps. To 
mitigate this risk an active role management program is implemented. The primary 
responsibility of the management of this program is the Career Management Team 
(CMT) system administrators. Users of the system should only have access to areas in 
which they have been granted privileges. If a user goes beyond the boundaries established 
by the system administrator, his or her account is locked out and system administrators 
will be notified of the breach. More specifically, in order to mitigate the risk between 
usability and security, access to resumes is granted only to employers and managers. The 
employers and manager website access will utilize a Common Access Card (CAC) with 
Public Key Infrastructure (PKI) to ensure those users accessing personal data are trusted. 
In order to keep usability high for our most important end users (the reservists), they will 
be able to login, browse and apply for billets, manager their resumes and view their 
personal information using only a strong password. The only personnel that would need 
to review resumes containing personal data are employers. All employers using this 
system will have access to CAC readers, and must have completed a DD 2875 (System 
Authorization Access Request) which signifies that the user has attended the required 
Information Assurance training. By PKI enabling the manager and employer portion of 
the system, it will be significantly more difficult to breach personal data. 

Additionally, specific ranges are added to each employers profile, for example, if 
the employer manages a Motor Transport IMA detachment, then they do not need to see 
the resume of a Gunnery Sergeant with an MOS of 3381 (Cook). When establishing his 
or her credentials the system could be designed to force the CMT system administrators 
to click checkboxes for each required MOS necessary for that specific billet manager. 
The Master access list will be maintained by Monster and updated by the CMT system 
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managers. This will ensure that the authorization tickets contained in the SOAP headers 
are able to identify a unique member and his or her access privileges. 

3. Security Concerns 

There is a significant security concern when government and commercial 
products are coupled. This system uses the hub and spoke architecture which decouples 
the systems and keeps them isolated from each other. Their only communication is 
through the intermediary hardware, which limits the threat. The system will use 
Customer Access Tickets (CAT), which are encrypted strings that include authentication 
information for the server sending the request (username/password and IP) to uniquely 
identify agencies, as well as, the users. This system guarantees the identity of the both 
entities. 

4. Data Entry Errors 

Due to volume of personnel entering data into the system, there is a significant 
risk of information inadvertently being modified or entered incorrectly. For example, an 
advertisement may be deleted accidentally or an application inputted might contain such 
mistakes as spelling or punctuation errors. To ensure that information is not changed or 
modified inadvertently by a rogue user, all information entered into the system will be 
tied to the system by the user’s unique identification. Only the author or a system 
administrator can change the document after it has been posted. Furthermore, all 
advertisements will be tied to the Billet Identification Code (BIC). A BIC is an II 
character alpha-numeric text block that uniquely identifies a billet within a specific 
reporting unit code table of organization. Employers are limited to posting 
advertisements for vacant billets for jobs that correspond to specific BICs assigned to 
their RUC; this will prevent any type of cross posting between employers and keep them 
from deleting one another’s advertisements. In the case of the lA/ADOS billets which do 
not have a BIC, all the input form data will be auto populated by a query of the 
MCTFS/TFSMS legacy systems. This will prevent dirty data from being entered into the 
system. 
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In order to ensure that all data that is used to auto populate applications used by 
the employers and the applicants, information will be drawn from the Marine Corps fixed 
data repositories (MCTFS/TFSMS). For example, in the case of the reservist’s resume, 
all information will be drawn directly from MCTFS with the exception of a free-form text 
block in which a reservist can input any additional information that is not MCTFS 
reportable. This block could include information relating to their civilian 
employment/school schedule. 

5. Potential Hidden Costs 

There are potential hidden costs due to the system being a hybrid solution. To 
mitigate this risk all costs will be defined, fixed and structured into the contract at the 
inception of the deal the following are some additional cost reduction strategies that can 
be employed: 

• A significant portion of the costs will be incurred at inception due to the nature of 
the solution being utilized, i.e. COTS technologies integrated with the PLA. Once 
the system is up and running, maintenance costs will be minimal, but the contract 
will be specific that Monster.com will be responsible for the life cycle 
maintenance of their systems. 

• Costs can also be controlled by prioritizing the wish list generated by the 
stakeholders of the system. The prioritization will be done by the key stakeholders 
to ensure that they agree to the ranking of the different attributes. “Wishes” with a 
low priority will only be funded if excess funds are available. 

• Interview other government agencies that are currently utilizing a Monster 
Government Solution (MGS). Analyze their contract (most government agencies 
shouldn’t treat these contracts as intellectual property), speak with their IT 
procurement department; find out where money could have been saved. Look for 
costs that can be minimized or avoided. These vendors often tack on numerous 
additional charges that may seem important or necessary, but ask other 
government monster users how important or necessary they really are. In the case 

the Marine Corps Reserve system, will their system really require that a Monster 

107 



contractor be on call that can troubleshoot the system in two minutes or less? 
This is not worth it for the Marine Corps Reserve, and money ean be saved by 
eliminating this requirement. 

• When interviewing other users of the MGS users determine who did the 
integration of legaey applieations with the new system. Determine what was their 
Capability Mature Model (CMM) level is, and determine if the projeet manager 
PMI eertified. The thought behind this it to use the lowest level of CMM possible 
to keep eosts down. 

• Don’t fall for bells and whistles you don’t need. For example, when buying ear it 
is easy to buy unneeessary upgrades or aeeessories. The same is true when 
negotiating what serviees will be provided by a COTS vendor. To minimize this 
risk the arehiteet must elearly define what is aetually required. By doing this 
numerous extra expenses ean be eliminated. 

• Build a eost matrix with following arguments inputted into a eost funetion: 

o Identifying eriteria - detailed eost list of the different serviees that are 
available for purehase. 

o Rating of eaeh eriterion - a weighting meehanism to adjust the eost of the 
different serviees. 

From this matrix a weighted total seore will be generated for eaeh alternative. 
Obviously more arguments ean be added to the funetion, but the point is you ean 
use this tool to determine if the eosts being eharged are agreeable. 

• If Monster utilizes an enterprise lieense agreement (ELA), ensure that detailed figures 
are obtained in regards to how eosts are ealeulated. For example, if Monster eharges 
per transaetions through the BGW, or eoneurrent users that must be known up front. 

These five risks obviously are not the only risks that the system will exposed to, 
but they do represent the most signifieant and viable threats to the proposed system. It is 
important that, at minimum, that these risks are aggressively managed and mitigated. 
Other risks that were identified but not addressed in this doeument inelude: 
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organizational buy-in, residual risks associated with the relationship between the COTS 
systems and government system and capacity concerns. Obviously, these are not all 
inclusive, but they make it apparent that before an actual system is selected another 
thorough examination of the risks needs to be conducted. 
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VII. SUMMARY, CONCLUSIONS AND FUTURE RESEARCH 


The primary objective of this thesis is to provide the Marine Corps with a 
thorough bottom up System Analysis of the next generation billet advertisement system 
that will replace RDOL. The analysis includes a detailed systems analysis, a generic 
architecture, logical data models, process models and a system model which provides the 
Marine Corps with a blueprint of the requirements for the next generation system of 
record. The secondary objective of this thesis was to analyze current system architectures 
that advertise and fill job vacancies within the Department of Defense (DoD), as well as 
commercial-off-the-shelf (COTS) products in order to identify what architecture should 
be leveraged by the Marine Corps during its next generation system. The combination of 
these two objectives will be coalesced together to form a roadmap for the Marine Corps 
to follow for the design of its next generation system. 

This chapter is organized as follows: First a summary of the results uncovered 
during literature review, examination of similar systems, and the system analysis and 
architectural design of the proposed system is presented. Second, conclusions drawn from 
this thesis research are presented and discussed. The third section provides direction for 
future research, focusing on improvements and refinements that will ultimately provide 
the Marine Corps with an optimal and adaptive system to advertise vacant reserve billets. 

A. SUMMARY OF FINDINGS 

I. Literature review 

We garnered valuable information from the analysis the Air Force’s ViPS, the 
Navy’s JOAPPLY, and Monster.com subsidiary USAJOBs. Specifically, we were able to 
capture industry best practices, and identify significant weaknesses and shortcomings that 
should be avoided in the design of the new system. These lessons learned were included 
in the logical design of the Marine Corps’ next generation system. Some of the more 
pertinent learning points collected from this literature review were: (1) The Air Force’s 
ViPS system was highly successful because of a thorough requirements analysis 
performed by the Air Force and the contractor SAIC during the design and development 
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of the system. The Marine Corps must build upon this idea and ensure that the 
stakeholder’s requirements are genuinely understood before building their next 
generation system. Beyond a detailed requirements analysis, the ViPS graphical user 
interface was intuitive and the functionality was sound, which makes it a tool that its 
stakeholders actually use. This currently isn’t the case for RDOL, and the next system 
fielded by the Marine Corps needs to address this deficiency. (2) The Navy’s JOAPPLY 
system provided a good example of how a user can use a web enable billet advertisement 
system to manage their career. Specifically, JOAPPLY provided a reservist with dynamic 
and robust set of career management tools that allowed him/her to be an active participant 
in the detailing process. Unfortunately, the system as a whole was built haphazardly and 
lacked other significant functionality, which, again, emphasizes the importance of system 
requirements analysis and documentation. The desirable career management attributes 
were incorporated into the quality attributes for the proposal of the next Marine Corps 
system. (3) The USAJOBs provided the Marine Corps with a pertinent and real example 
of how the government can harness the synergy and prowess of mature turnkey COTS 
product. This product also provided the blueprint of an architecture that is viable for a 
web enable billet advertisement system. 

2. Results of System Analysis 

The primary reason the current system failed is due to the lack of a 
comprehensive requirements analysis at the inception of the project. During the 
requirements analysis for RDOL, the majority of pertinent stakeholders were excluded 
from the process, which resulted in a fragmented and incomplete system specification. 
Therefore, the emphasis of this thesis has been on specifying all of the stakeholder’s 
requirements for the next generation Marine Corps billet advertisement system. This was 
accomplished by identifying the stakeholder’s requirements for an ideal billet 
advertisement system through interviews and working groups. The results were broken 
into two functional areas: Data Business Requirements and Process Business 
Requirements. 

The Data Business Requirements section focused on the data and the data 

structure required for the next system to be successful. This analysis revealed four main 
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top-level entities. These are candidates, employers, managers and recruiters. The 
attributes and the relationships between these entities were expanded upon using an 
Entity Relationship Diagram. Ultimately, this process captured the basic data structure 
required for this system to be successful, but these only represent a high-level view of the 
data structure for the system. The Marine Corps needs to refine these data requirements 
before they complete the acquisition process. 

The Process Business Requirements defined the scope of the system, as well as, 
the functional requirements of the system. The scope of the system is presented in a 
Context Data Flow Diagram. This diagram clearly defines the external interactions and 
boundaries of the proposed system. This process model was further refined by using a 
Functional Decomposition Diagram, which expands upon the system by breaking it down 
into its core functional constituents. These are the candidates, employers, managers and 
recruiters. These four sub-groups are further broken down into their core functional 
requirements or each sub-group which are expanded upon and defined by use cases. 

3. Results of Architecture Analysis 

The results of the requirements analysis yielded enough information to identify 
specific components that can be used by the system, but this analysis did not address the 
framework, or architecture, that needs to be implemented to support these components. 
To address this disparity, the Architecture Tradeoff Analysis Method (ATAM) was used 
to identify an appropriate architecture to meet the needs of the proposed system. The 
ATAM is a nine-step methodology for evaluating architecture designs that uses 
stakeholder defined quality attributes as a metrics to gauge whether or not the proposed 
architecture will meet its defined objectives. 

The ATAM process, along with the results of the systems analysis and literature 
review, identified the hub and spoke topology as the best solution for this project. It 
afforded the Marine Corps with the most robust and versatile solution for its problem set. 
Using scenarios as a medium, quality attributes were used to measure the effectiveness of 
the proposed architecture. In the instances that were substantiated, the proposed 
architecture met all of the requirements defined by the quality attributes, and the 
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proposed architecture appears to be viable and a good selection. But further analysis is 
needed as only a small subset of the quality attributes have been used to stress the 
proposed architecture, and a more thorough testing has to be completed before the Marine 
Corps can unequivocally call the proposed architecture the right one. 

The ATAM also provided additional findings that were useful to the project. 
Specifically, it helped further define and clarify stakeholder requirements; it identified 
some potential risks early in the life-cycle of the system, and an increased communication 
among stakeholders. The analysis also made it apparent that the complexity inherent in 
designing a real world web application for numerous stakeholders that architecture 
tradeoff analysis is rarely a straightforward activity. Each step of the ATAM answered 
some design questions, but it also brought some issues to light that we had neglected to 
focus on. 

B. CONCLUSIONS 

The problems and issues surrounding RDOL can be eliminated. It will, however, 
take time, money, and the combined effort on the part of many people. In the midst of 
the long war, it is clearly evident that the reserve is an integral part of the Marine Corps 
total force. This integration hinges on the recognition that the ability for our reservists to 
be able to easily search and identify available opportunities is of the utmost importance. 
Additionally, it is equivocally important for employers to have those same abilities to 
seek out potential reservists to fill various types of reserve billets. The current manpower 
struggles the Marine Corps faces requires that we do our best to put our reserve Marines 
in the right billets at the right time. The proposed architecture and requirements analysis 
presented in this thesis will provide a solid foundation for the next generation system, 
but, as noted earlier, more work has to be done to ensure that the Marine Corps does not 
build a system that does not fully meet its requirements. 
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C. FUTURE RESEARCH 

While this thesis focused on understanding the requirements and design of the 
new system, there is a considerable amount of work that needs to be accomplished. This 
work includes the completion of the remaining steps of the FAST and ATAM 
methodologies which include: 

Decision Analysis: During this phase candidate solutions are identified, 
feasibility analysis is conducted, and a candidate system is recommended that best fits the 
needs of the Marine Corps. Feasibility analysis includes technical, operational, economic, 
schedule and risk feasibility. At the end of this phase, a system proposal is generated 
which will include conclusions and recommendations. 

Physical Design: This phase commences once a candidate solution has been 
selected, and has proven to be feasible. It takes the logical model and converts it into an 
operating physical model. At this point a determination on what technologies best 
provide a solution to the problem domain will be decided upon, such as, the technical 
requirements of the database and any software or middleware requirements. Upon 
completion of this phase an operating prototype is built. 

Construction and testing: Once the physical model is built, developers can begin 
constructing and testing components of the system. During this phase developers begin 
beta testing the prototype built in the Physical Design phase. Results from the beta-testing 
are delivered to major stakeholders. 

Installation and delivery: Once construction and testing are complete, the 
system can be delivered and installed. This step would be addressed by Headquarters 
Marine Corps. 

Another element not addressed by this thesis work is the important element of 
cost. Specifically, a detailed cost analysis of proposed COTS hybrid solutions needs to be 
completed. 
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Finally a feasibility study focused on the viability of porting the Air Force ViPS 
application and modifying it to become a Marine Corps system of record. Our 
discussions with the Air Force revealed that they own the source code and all the 
necessary documentation. Although our personnel systems are different, ViPS currently 
meets many of the requirements and quality attributes documented in this thesis work. 

In conclusion, we strongly believe the results and recommendations of this thesis 
provide the Marine Corps with a solid foundation for developing the next generation 
Marine Corps Reserve Billet Advertisement System. In addition, the thesis provides an 
archetype that can be leveraged by the Marine Corps in building other future systems. 
This will not only result in money savings, but will ultimately result in better and more 
robust future Marine Corps application systems. At a minimum, both of these results and 
recommendations ensure that the Marine Corps will produce a much superior Billet 
Advertisement System than the existing one. 
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APPENDIX A. USE CASE GLOSSARY 


CANDIDATE USE CASES 

Id 

Use-Case Name 

Use-Case Description 

Participating Actors and Roles 

1 

Contact employer for 
additional information 

This use case describes how a 
candidate can submit 
information to an employer to 
gain additional details about an 
advertisement. 

Candidate (Primary Actor) 

Employer (System Actor) 

2 

Create Application 

This Use Case describes how a 
Candidate applies for an 
advertised billet. (Member may 
apply for multiple positions.) 

Candidate (Primary Actor) 

Employer (Primary Actor) 

3 

Review Application 

This Use Case describes how a 
Candidate reviews all the billets 
they have applied for. (No 
historical data will be 
displayed.) 

Candidate (Primary Actor) 

4 

Update Application 

This Use Case describes how a 
Candidate updates a current 
application that has already 
been submitted. (Application 
can be updated as long as it has 
not been approved by an 
Employer.) 

Candidate (Primary Actor) 

Employer (Primary Actor) 

5 

Delete Application 

This Use Case describes how a 
Candidate deletes an application 
that has been previously 
submitted. 

Candidate (Primary Actor) 

Employer (Primary Actor) 

6 

Create Billet Lead 
Subscription 

This Use Case describes how a 
Candidate can create a 
subscription to receive updates 
(email or notification on portal) 
if new billets that fit his or her 
criteria (geo loc, dates) have 
been posted, updated or deleted. 

Candidate (Primary Actor) 

Employer (External Receiver) 
Recruiter (External Receiver) 

7 

Review Billet Lead 
Subscription 

This Use Case describes how a 
Candidate can review their 
subscriptions without making 
any modifications to them. 

Candidate (Primary Actor) 

8 

Update Billet Lead 
Subscription 

This Use Case describes how a 
Candidate can modify their 
current subscriptions. 

Candidate (Primary Actor) 

Employer (External Receiver) 
Recruiter (External Receiver) 

9 

Delete Billet Lead 
Subscription 

This Use Case describes how a 
Candidate can delete any of 
their current subscriptions. 

Candidate (Primary Actor) 

Employer (External Receiver) 
Recruiter (External Receiver) 

10 

Create personal web 
portal content 

This use case describes how a 
candidate can create a 
personalized web portal upon 
initial login. 

Candidate (Primary Actor) 


117 





Id 

Use-Case Name 

Use-Case Description 

Participating Actors and Roles 

11 

Review personal web 
portal content 

This use case describes how a 
candidate can review the 
customizable information 
contained within their personal 
web portal (e.g. RSS feeds, 
content) 

Candidate (Primary Actor) 

12 

Update personal web 
portal content 

This use case describes how a 
candidate can update the 
customizable information 
contained within their personal 
web portal (e.g. RSS feeds, 
content) 

Candidate (Primary Actor) 

13 

Delete personal web 
portal content 

This use case describes how a 
candidate can delete the 
customizable information 
contained within their personal 
web portal (e.g. RSS feeds, 
content) 

Candidate (Primary Actor) 

14 

Use External Marine 
Corps Services 

This Use Case describes how a 
Candidate can use external links 
to manage their career. 

Candidate (Primary Actor) 

15 

Review Application 
History 

This use case describes how a 
candidate can view the current 
details of all active and prior 
billet applications. 

Candidate (Primary Actor) 

16 

Participate in 
community events 

This Use Case describes how a 
Candidate can use the 
community tools available in 
the RBAS system. 

Candidate (Primary Actor) 

Employer (External Receiver) 
Recruiter (External Receiver) 

17 

Search Available 
Advertisements 

This Use Case describes how a 
Candidate can search for jobs 
posted by Employers that match 
their search criteria. 

Candidate (Primary Actor) 

Employer (Primary Actor) 

18 

View applicant pool for 
an active advertisement 

This use case describes how a 
candidate can view the current 
details of an active 
advertisement with respect to 
other candidates that have 
applied for a billet. 

Candidate (Primary Actor) 

19 

Create Reserve 
Qualification Summary 

This use case describes how a 
candidate can create an 
electronic Reserve Qualification 
Summary (RQS). 

Candidate (Primary Actor) 

Employer (External Receiver) 
Recruiter (External Receiver) 

20 

Review Reserve 
Qualification Summary 

This use case describes how a 
candidate can review their 
electronic Reserve Qualification 
Summary (RQS). 

Candidate (Primary Actor) 

21 

Update Reserve 
Qualification Summary 

This use case describes how a 
candidate can update their 
electronic Reserve Qualification 
Summary (RQS). 

Candidate (Primary Actor) 

Employer (External Receiver) 
Recruiter (External Receiver) 
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Id 

Use-Case Name 

Use-Case Description 

Participating Actors and Roles 

22 

Delete Reserve 
Qualification Summary 

This use case describes how a 
candidate can delete their 
electronic Reserve Qualification 
Summary (RQS). 

Candidate (Primary Actor) 

Employer (External Receiver) 
Recruiter (External Receiver) 

23 

Manage Billet Leads 

This Use Case describes how a 
Candidate can manage all leads 
that have been generated for 
advertisements that are included 
in their subscriptions. 

Candidate (Primary Actor) 

Employer (System Actor) 

RECRUITER USE CASES 

1 

Search all available 
billets 

This Use Case describes how a 
recruiter can search for billets 
that match their search criteria 
(MOS, GeoLoc, Dates). 

Recruiter (Primary Actor) 

Employer (External Server) 

2 

Search all available 
candidates. 

This Use Case describes how a 
Recruiter can search all 
available candidates by specific 
criteria (MOS, rank, geo loc, 
dates). 

Recruiter (Primary Actor) 

3 

Manage Candidate 

Leads 

This Use Case describes how a 
Recruiter can manage all leads 
that have been generated for 
billets that are included in their 
district. 

Recruiter (Primary Actor) 

Candidate (External Server) 

4 

View Adhoc Report 

This Use Case describes how a 
Recruiter generates and views 
an adhoc report. 

Recruiter (Primary Actor) 

5 

View Vacant Billet 

Report 

This Use Case describes how a 
Recruiter views a report 
containing ALL vacant billets 
with or without the use of a 
filter. 

Recruiter (Primary Actor) 

6 

Create Personal Web 
Portal Content 

This use case describes how a 
Recruiter can create a 
personalized web portal upon 
initial login. 

Recruiter (Primary Actor) 

Manager (External Actor) 

7 

Review Personal Web 
Portal Content 

This use case describes how a 
Recruiter can review the 
customizable information 
contained within their personal 
web portal (e.g. RSS feeds, 
content) 

Recruiter (Primary Actor) 

8 

Update Personal Web 
Portal Content 

This use case describes how a 
Recruiter can update the 
customizable information 
contained within their personal 
web portal (e.g. RSS feeds, 
content) 

Recruiter (Primary Actor) 

9 

Delete Personal Web 
Portal Content 

This use case describes how a 
Recruiter can delete the 
customizable information 
contained within their personal 
web portal (e.g. RSS feeds) 

Recruiter (Primary Actor) 
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Id 

Use-Case Name 

Use-Case Description 

Participating Actors and Roles 

10 

Create Candidate Lead 
Subscription 

This Use Case describes how a 
Recruiter can create a 
subscription to receive updates 
(email or notification on portal) 
if new candidates that fit his or 
her criteria (geo loc, dates, 

MOS) have been posted, 
updated or deleted. 

Recruiter (Primary Actor) 

Candidate (External Server) 

11 

Review Candidate Lead 
Subscription 

This Use Case describes how a 
Recruiter can review their 
subscriptions without making 
any modifications to them. 

Recruiter (Primary Actor) 

12 

Update Candidate Lead 
Subscription 

This Use Case describes how a 
Recruiter can update their 
current subscriptions. 

Recruiter (Primary Actor) 

Candidate (External Server) 

13 

Delete Candidate Lead 
Subscription 

This Use Case describes how a 
Recruiter can delete any of their 
current subscriptions. 

Recruiter (Primary Actor) 

Candidate (External Server) 

14 

Facilitate community 
events 

This use case describes how a 
Recruiter manages the forum 
and blog contents within their 
recruiting district. 

Recruiter (Primary Actor) 

Employer (External Server) 

Candidate (External Server) 

MANAGER USE CASES 

1 

Create Roles For Users 
or Groups of RBAS 

This Use Case describes how 
system managers control the 
access and privileges of system 
users by creating individual and 
group accounts. 

System Manager (Primary Actor) 
Employer (External Receiver) 
Candidate (External Receiver) 
Recruiter (External Receiver) 

2 

Review Roles For Users 
or Groups of RBAS 

This Use Case describes how 
system managers can review the 
roles and rights assigned roles 
to a user or a group. 

System Manager (Primary Actor) 

3 

Update Roles For Users 
or Groups of RBAS 

This Use Case describes how 
system managers can 
update/modify the access and 
capabilities of system 
users/groups. 

System Manager (Primary Actor) 
Employer (External Receiver) 
Candidate (External Receiver) 
Recruiter (External Receiver) 

4 

Delete Roles For Users 
or Groups of RBAS 

This Use Case describes how 
system managers can delete the 
access and capabilities of 
system users/groups. 

System Manager (Primary Actor) 
Employer (External Receiver) 
Candidate (External Receiver) 
Recruiter (External Receiver) 

5 

Create Personal Content 
for Management and 

Site Portals 

This Use Case describes how a 
System Manager can create 
content for the management 
web portal as well as control the 
core content for the entire 

RBAS site. 

System Manager (Primary Actor) 
Employer (External Receiver) 
Candidate (External Receiver) 
Recruiter (External Receiver) 

6 

Review Management 
and Site Web Portal 
Content 

This Use Case describes how a 
System Manager can review 
settings for both the Managerial 
and Site web portal for the 
Reserve Billet Advertisement 
System. 

System Manager (Primary Actor) 
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Id 

Use-Case Name 

Use-Case Description 

Participating Actors and Roles 

7 

Update Management 
and Site Web Portal 
Content 

This Use Case describes how 
system managers can update 
overall system portal content, 
(e.g.: broadcast messages to 

ALL system users.) 

System Manager (Primary Actor) 
Employer (External Receiver) 
Candidate (External Receiver) 
Recruiter (External Receiver) 

8 

Delete Management and 
Site Web Portal Content 

This Use Case describes how a 
System Manager can delete 
settings for the Management or 
Site web portal for the Reserve 
Billet Advertisement System. 

System Manager (Primary Actor) 
Employer (External Receiver) 
Candidate (External Receiver) 
Recruiter (External Receiver) 

9 

Generate adhoc reports 

This Use Case describes how a 
System Manager generates and 
views ad hoc reports. 

System Manager (Primary Actor) 

10 

Generate detailed user 
report 

This Use Case describes how a 
System Manager generates a 
detailed report on an individual 
user. 

System Manager (Primary Actor) 

11 

Generate system usage 
report 

This Use Case describes how a 
System Manager generates a 
report that tracks the use of the 
RBAS system. 

System Manager (Primary Actor) 

12 

Generate user overview 
report 

This Use Case describes how a 
System Manager generates a 
report that displays all the users 
of a specific group or category 
that is registered in the RBAS 
system. 

System Manager (Primary Actor) 

13 

Ensure all form input 
data is valid and 
complete 

This Use Case describes how 
the RBAS system automatically 
checks all input for 
completeness and accuracy. 

System (Primary Actor) 

System Manager (External 

Receiver) 

Employer (External Receiver) 
Candidate (External Receiver) 
Recruiter (External Receiver) 

14 

Automated Update of 
Candidate Table 

This use case describes how a 
candidate's personal information 
gets populated from MCTLS. 

System (Primary Actor) 

15 

Automated Update of 
MOS Table 

This use case describes how the 
MOS table gets populated from 
MCTLS. 

System (Primary Actor) 
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Id 

Use-Case Name 

Use-Case Description 

Participating Actors and Roles 

16 

Perform Limited 
Modification to the 
System. 

This Use Case describes how 
system managers will be able to 
modify limited website content, 
(e.g.: change aesthetics of web 
front end, style sheets, 
nomenclature e.g. ADSW to 
ADOS) 

Manager (Primary Actor) 

Candidate (External Receiver) 
Recruiter (External Receiver) 
Employer (External Receiver) 

17 

Ensure that user 
credentials are verified 
by use of CAC or strong 
password during login 
process 

This use case describes the 
system actions performed when 
a user logons to the system. 
Credentials will be verified with 
a Common Access Card (CAC) 
or strong password. 

System (Primary Actor) 

Manager (External Server) 

Candidate (External Server) 

Recruiter (External Server) 

Employer (External Server) 

18 

Manage Trouble Call 
Queue 

This Use Case describes how 
managers will be able to view 
and manage all trouble calls 
submitted by users of the 
system. 

Manager (Primary Actor) 

Candidate (External Server) 

Recruiter (External Server) 

EMPLOYER USE CASES 

1 

Create Advertisement 

This use-case describes the 
action of manually inputting a 
new billet/advertisement into 
the system to be viewed by 
potential candidates. 

Employer (Primary Actor) 

Candidate (External Receiver) 
Recruiter (External Receiver) 

2 

Review Advertisement 

This Use Case describes how an 
Employer manually reviews all 
the advertisements they have 
created which are currently 
posted. 

Employer (Primary Actor) 

3 

Update Advertisement 

This use-case describes the 
action of updating a manually 
inputted billet/advertisement in 
the system. 

Employer (Primary Actor) 

Candidate (External Receiver) 
Recruiter (External Receiver) 

4 

Delete Advertisement 

This use-case describes the 
action of deleting a manually 
inputted billet/advertisement 
from the system. 

Employer (Primary Actor) 

Candidate (External Receiver) 
Recruiter (External Receiver) 

5 

Create automated 
advertisement 

This use case describes how the 
system generates billet 
advertisements automatically by 
comparing MCTES O/H data 
versus T/O data. 

Employer System (Primary Actor) 
MCTES/TESMS (External Server) 
Recruiter (External Receiver) 
Candidate (External Receiver) 
Employer (External Receiver) 


122 





Id 

Use-Case Name 

Use-Case Description 

Participating Actors and Roles 

6 

Create subscription to 
automated candidate 
search services 

This Use Case describes how an 
Employer can create a 
subscription to automatically 
receive updates (email or 
notification on portal) if new 
candidates that fit his or her 
criteria (geo loc, dates, MOS) 
have recently registered, posted 
new or updated information or 
deleted items from their profile. 

Employer (Primary Actor) 

Candidate (External Server) 

7 

Review subscription to 
automated candidate 
search services 

This Use Case describes how an 
employer can review their 
subscriptions without making 
any modifications to them. 

Employer (Primary Actor) 

8 

Update subscription to 
automated candidate 
search services 

This Use Case describes how an 
employer can modify their 
current subscriptions. 

Employer (Primary Actor) 

Candidate (External Server) 

9 

Delete subscription to 
automated candidate 
search services 

This Use Case describes how an 
employer can delete any of their 
current subscriptions. 

Employer (Primary Actor) 

Candidate (External Server) 

10 

View current application 
pool 

This use case describes how an 
employer can view all 
leads/applications that have 
been submitted for billets in 
their purview. 

Employer (Primary Actor) 

Candidate (External Server) 

11 

Verify validity of 
automated billet 
generation 

This Use Case describes how 
Employers verify the billets 
generated automatically by the 
RBAS system. 

Employer (Primary Actor) 

Candidate (External Receiver) 
Recruiter (External Receiver) 

12 

Manually search all 
Candidates by avenue of 
interest (MOS/Dates) 

This Use Case describes how an 
Employer can search for 
interested Candidates that match 
their search criteria. 

Employer (Primary Actor) 

Candidate (External Server) 

13 

Hire Candidate 

This use case describes how an 
employer selects a particular 
candidate for a billet. 

Employer (Primary Actor) 

Candidate (External Receiver) 
Recruiter (External Receiver) 

14 

Reject Candidate 

This use case describes how an 
employer rejects a particular 
candidate for a billet. 

Employer (Primary Actor) 

Candidate (External Receiver) 
Recruiter (External Receiver) 

15 

Communicate with 
candidate pool 

This use case describes how an 
Employer can conduct mass 
communication with all 
candidates applying for a 
specific billet. 

Employer (Primary Actor) 

Candidate (External Receiver) 

16 

Communicate with 
potential candidates 

This use case describes how an 
Employer can conduct mass 
communication with all 
candidates who might be 
interested in a specific billet. 

(e.g.: New billet for a 0659 
opens up, employer can 
communicate with all RBAS 
users with 06XX MOS.) 

Employer (Primary Actor) 

Candidate (External Receiver) 
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Id 

Use-Case Name 

Use-Case Description 

Participating Actors and Roles 

17 

Create employer web 
portal content 

This use case describes how an 
employer can create a 
personalized web portal upon 
initial login. 

Employer (Primary Actor) 

18 

Review employer web 
portal content 

This use case describes how an 
employer can review the 
customizable information 
contained within their personal 
web portal (e.g.: RSS feeds, 
content) 

Employer (Primary Actor) 

19 

Update employer web 
portal content 

This use case describes how an 
employer can update the 
customizable information 
contained within their personal 
web portal (e.g.; RSS feeds, 
content) 

Employer (Primary Actor) 

20 

Delete employer web 
portal content 

This use case describes how an 
employer can delete the 
customizable information 
contained within their personal 
web portal (e.g.: RSS feeds, 
content) 

Employer (Primary Actor) 

21 

Generate adhoc reports 

This Use Case describes how an 
Employer generates and views 
ad hoc reports. 

Employer (Primary Actor) 

22 

Generate advertisement 
history 

This use case describes how an 
employer can view a report 
which displays advertisement 
history information for all 
current applications. 

Employer (Primary Actor) 

23 

Generate detailed 
advertisement report 

This use case describes how an 
employer can generate a report 
which lists the details of all 
current advertisements. 

Employer (Primary Actor) 

24 

Generate advertisement 
response report 

This use case describes how an 
employer can view a report 
which displays advertisement 
response information for all 
current applications. 

Employer (Primary Actor) 

25 

Generate timed 
report/email (30/14/0/- 
14) 

This use case describes how the 
system generates a temporal 
report/email which outlines the 
billets that will expire soon. 

Employer System (Primary Actor) 
Candidate (External Receiver) 
Employer (External Receiver) 

26 

Manage Candidate 

Leads 

This Use Case describes how an 
Employer can manage all leads 
that have been generated for 
advertisements that are included 
in their purview. 

Employer (Primary Actor) 

Candidate (External Server) 
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APPENDIX B. CANDIDATE USE CASES 


Candidate Subsystem 


USE CASE NAME: 

Contact employer for additional 
information 

USE CASE TYPE 

PRIORITY: 

Low 

System Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

DESCRIPTION: 

This Use Case describes how a candidate can contact an employer for 
additional information about an advertisement. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

Candidate clicks on contact employer link within an advertisement. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: Candidate actuates 
additional information link 
within an advertisement. 


Step 3: The user inputs desired 
request and clicks “submit”. 


Step 2: System opens a request form 
window. 


Step 4: System checks validity of 
information and transmits an email and 
presents a success message. 


ALTERNATE 

COURSES: 


AA Step 3: System reports error if link is not operational. Error message is 
displayed. 


SR Step 4: If information is not valid, system reports error to user. 


AA Step 5: User corrects information and clicks submit. Process re-enters 
at step 4. 


CONCLUSION: 


Candidate has successfully transmitted information request to employer. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Contact Employer Process Model 


Additional 


Hinail 
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Candidate Subsystem 


USE CASE NAME: 

Create Application 

USE CASE TYPE 

PRIORITY: 

High 


SOURCE: 

System Requirement 

System Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This Use Case describes how a candidate applies for an advertised billet. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The Use Case is initiated when the candidate submits an application. 

TYPICAU COURSE 

Actor Action 

System Response 

OF EVENTS: 

Step 1; The candidate applies 
for a billet advertised on the 

Step 2: The system verifies that all of the 
required fields are filled out in the input 


website by clicking on the 
hyper link or “apply for” button 
associated with the desired 
billet. 

form. 




Step 3: The system verifies that the billet 
being applied for is still valid. 


Step 5: The candidate responds 
positively to system prompt. 

Step 4: System prompts user on whether 
they are sure that they want to submit this 
application. 



Step 6: The system accepts the 
application and stores it. 



Step 7: The system updates the 
applicable employer application queue 
for that billet. 



Step 8: The system generates leads for 
Employers and Recruiters that have 
subscribed to automated candidate search 



services. 



Step 9: The system generates a tickler 
email for the employer advertising the 
billet and the recruiter in the appropriate 
district. 



Step 10: The system generates an email 
for the candidate acknowledging the 
systems acceptance of their application. 

AUTERNATE 

COURSES: 

SR Step 3: All the required information not present, error message sent to 
user. 


AA Step 4: Candidate corrects the error and resubmits. 


Return to step 4 of the “Typical Course of Events” 


OR 


AA Step 5: The candidate responds negatively to system prompt and 
request is canceled. 
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Candidate Subsystem 
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Candidate Subsystem 


USE CASE NAME: 

Update Application 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

System Requirement 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This Use Case describes how a Reservist updates a current application that 
was submitted. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

The candidate currently has at least one active application. 

TRIGGER: 

The candidate selects an application to update from their queue. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The candidate selects 
an application to update from 
their queue by clicking on the 
hyperlink or the update button 
associated with that application. 

Step 2: The system checks the status of 
the application that the candidate desires 
to update. 


Step 3: If the application has not been 
selected or being processed and the 
information is not personal information 
housed in MCTFS, the system will honor 
the update request of the candidate. 


Step 4: The system generates an email to 
the candidate that acknowledges the 
success of the update operation. 


Step 5: A tickler email is sent to the 
Employer and Recruiter notifying them 
of the change. 

AUTERNATE 

COURSES: 

Step 3: If the update requested is personal information the candidate will be 
directed to services provided by Marine OnLine (MOL) to complete the 
transaction. 

CONCUUSION: 

The application is successfully updated the information that required 
changes. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 

1. Application can be updated as long as the application is in the pre¬ 
approval status. 

2. The candidate cannot update personal information without going through 
the appropriate channels. 

IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Candidate Subsystem 


USE CASE NAME: 

Delete Application 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

System Requirement 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This Use Case describes how a Reservist deletes an application that has 
been previously submitted. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

The candidate currently has at least one active application. 

TRIGGER: 

The candidate selects an application that they want to delete. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The candidate selects 
an application to delete from 
their queue by clicking on the 
hyper link or the delete button 
associated with that application. 

Step 2: The system checks the status of 
the application that the candidate wishes 
to delete. 


Step 3: If the application has not been 
selected and being processed, the system 
will honor the delete request of the 
candidate. 


Step 4: The employer’s application 
queue for this advertisement is updated. 


Step 5: The candidate’s active 
application queue is updated. 


Step 5: A tickler email is sent to the 
Employer notifying them of the deletion. 


Step 6: The system generates an email to 
the candidate that acknowledges the 
success of the delete operation. 


Step 7: A tickler email is sent to the 
Employer and Recruiter notifying them 
of the deletion. 

AUTERNATE 

COURSES: 

Step 3: If the application has been selected and being processed therefore 
the system will NOT honor the delete request of the candidate. 

CONCUUSION: 

The application is deleted and the candidate’s active application queue is 
updated. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 

Application can be updated as long as the application is in the pre-approval 
status. 

The candidate cannot update personal information without going through 
the appropriate channels. 

IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Candidate Subsystem 


USE CASE NAME: 

Create Billet Lead Subscription 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This Use Case describes how a Candidate can create a subscription to 
receive updates (email or notification on portal) if new billets that fit his or 
her criteria (geo loc, dates) have been posted, updated or deleted. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The candidate wants to create a subscription service within RBAS. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step I: Candidate with roles 
clicks “Create Subscription” 

Step 2: Screen with subscription criteria 
(MOS, GeoLoc, Dates) appears for 
candidate to select or input. 

Step 3: Candidate completes 
form and clicks submit. 

Step 4: The system verifies the 
information. 


Step 5: If the information is correct, the 
system accepts the subscription. 


Step 6: The system places the employer 
and their search criteria in its 
subscription queue. 


Step 7: Leads are generated for 
employers and recruiters that have 
subscribed to candidate search services. 


Step 8: The system compares the criteria 
of newly posted, updated or deleted 
billets versus the criteria posted by 
subscribers. 

AETERNATE 

COURSES: 

SR Step 2: The system rejects the application because of incomplete or 
improper data. 

AA Step 3: The user corrects the data, resubmits and reenters the process at 
step #2 of the “typical course of events.” 

CONCUUSION: 

Candidate has successfully created a subscription service to receive leads 
automatically. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Candidate Subsystem 


USE CASE NAME: 

Review Billet Lead Subscription 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This Use Case describes how a Candidate can review all active 
subscriptions. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

The candidate has active subscription(s). 

TRIGGER: 

The candidate chooses to review an active subscription in the RBAS 
subscription portal. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: The candidate selects 
“view” subscription from menu 
of choices. 


Step 2: The system will query the 
database to retrieve the candidate’s 
subscription information. 


Step 3: Once an active record is found, 
the system will display the retrieved 
subscription information. 


ALTERNATE 

COURSES: 


SR Step 3: The system is unable to locate a subscription for the candidate. 


SR Step 4: The system displays an error message that informs the candidate 
that he or she has no active subscriptions. 


CONCLUSION: 


Candidate successfully reviews active subscriptions. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Review Subseription Proeess Model 


Candidate 


Request 

Active 

S<ihscription!i 


t 


icccptancc 

Notiiication 


Ouent' For 
Suhseription 


Review 
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Candidate Subsystem 


USE CASE NAME: 

Update Billet Lead Subscription 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This Use Case describes how a Candidate can update an active subscription. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

The candidate has active subscription(s). 

TRIGGER: 

The candidate chooses to update an active subscription in the RBAS 
subscription portal. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The candidate selects 
“update” subscription from 
menu of choices. 

Step 2: The system will query the 
database to retrieve the candidate’s 
subscription information. 


Step 3: Once an active record is found, 
the system will prompt candidate to 
verify if the information retrieved is the 
subscription they want to update. 

Step 4: The candidate verifies 
the information and 
acknowledges by pressing 
continue. 

Step 5: The system then opens a 
subscription edit window and populates 
the fields with the retrieved information 
and prompts the user to update the 
subscription. 

Step 6: The candidate updates 
the information and hits 
“submit” when complete. 

Step 7: The system error checks the 
information, if the information is correct 
the update is accepted, acknowledged 
and the database is updated. 


Step 8: The system places the candidate 
and their search criteria in its 
subscription queue. 


Step 9: Leads are generated for 
employers and recruiters that have 
subscribed to candidate search services. 


Step 10: The system compares the billet 
identifiers of newly posted, updated or 
deleted jobs versus the criteria posted by 
subscribers. 


Step 11: If the search criteria matches, an 
email is generated and sent to the 
candidate or his portal is updated, (which 
ever method is selected) 
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ALTERNATE 

COURSES: 


SR Step 3: The system is unable to locate a subscription for the candidate. 


SR Step 4: The system displays an error message that informs the candidate 
that he or she has no active subscriptions. 


AA Step 6: The candidate declines to update the subscription. 


SR Step 7: The system acknowledges the negative response and deletes the 
transaction. 


SR Step 8: The system display successful cancelation message to user. 


CONCLUSION: 


The candidate updates an active subscription. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Update Subscription Process Model 
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Candidate Subsystem 


USE CASE NAME: 

Delete Billet Lead Subscription 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This Use Case describes how a Candidate can delete an active subscription. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

The candidate has active subscriptions. 

TRIGGER: 

The candidate chooses to delete an active subscription in the RBAS 
subscription portal. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The candidate selects 
“delete” subscription from 
menu of choices. 

Step 2: The system will query the 
database to retrieve the candidate’s 
subscription information. 


Step 3: Once an active record is found, 
the system will prompt candidate to 
verify if the information retrieved is the 
subscription they want deleted. 

Step 4: The candidate verifies 
the information and 
acknowledges by pressing 
continue. 

Step 5: The system then prompts the 
candidate if they are certain they want to 
cancel this subscription. 

Step 6: The candidate 
acknowledges his or her 
approval by clicking “yes” 

Step 7: The system receives the response 
and deletes the subscription from the 
database 


Step 8: A success message is generated 
and displayed to the candidate. 

AUTERNATE 

COURSES: 

SR Step 3: The system is unable to locate a subscription for the candidate. 

SR Step 4: The system displays an error message that informs the candidate 
that he or she has no active subscriptions. 

AA Step 6: The candidate declines to delete subscription. 

SR Step 7: The system acknowledges the negative response and deletes the 
transaction. 

SR Step 8: The system display successful cancelation message to user. 

CONCUUSION: 

The candidate deletes an active subscription. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Candidate Subsystem 


USE CASE NAME: 

Create personal web portal content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how a candidate can create a personalized web 
portal upon initial login to the Reserve Billet Advertisement System. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The candidate subscribes to service via RBAS. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The candidate logons to 
RBAS for the first time. 

Step 2: The system prompts the user to 
select what content they want to add to 
their personal portal. The user will be 
provided with a list of alternatives to 
select from. 

Step 3: The candidate selects 
the services that he or she wants 
to populate their personal portal 
with. When the candidate is 
done choosing, he or she hits 
“submit” to transmit settings 
back to RBAS. 

Step 4: RBAS acknowledges the request, 
and updates the candidate’s preferences 
queue and updates the database. 


Step 5: The system sends a positive 
response acknowledging changes and 
instructs user to log off and on to view 
the changes. 

AUTERNATE 

COURSES: 

None 

CONCUUSION: 

The candidate personalizes their web portal. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Create Portal Settings Process Model 
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Candidate Subsystem 


USE CASE NAME: 

Review personal web portal content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how a candidate can review settings for their 
personalized web portal in Reserve Billet Advertisement System. 

PRE-CONDITION: 

The candidate is registered Reserve Billet Advertisement System and have 
been assigned the appropriate level of access. 

The candidate is logged into RBAS. 

TRIGGER: 

The candidate reviews personal setting for personal portal in RBAS. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The candidate selects 
“view” portal settings from 
menu of choices. 

Step 2: The system queries the database 
for the candidate’s currents settings. 


Step 3: If the candidate has personal 
settings, RBAS displays the queries 
results. 

AUTERNATE 

COURSES: 

SR Step 3; The candidate doesn’t have any portal settings and the system 
displays an error message. 


CONCUUSION: 

The candidate reviews their personal web portal settings. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 

Candidate 

Revit 

Kcqurst Portal 
Scuitiipi 

Portal Settings Process Model 

yiicty For 

Candidates 

Portal Values 


Review Web 

Portal 


Accqitancc 
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Candidate Subsystem 


USE CASE NAME: 

Update personal web portal content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how a candidate can update their personalized web 
portal in the Reserve Billet Advertisement System. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

The candidate is logged into RBAS. 

TRIGGER: 

The candidate chooses to update their personal web portal content in RBAS. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step 1: The candidate selects 
“update” portal settings from 
menu of choices. 

Step 2: The system queries the database, 
populates the list of alternatives with 
current settings. 


Step 3: The system prompts the 
candidate to update their selections. 

Step 3: The candidate selects 
the services that he or she wants 
to populate their personal portal 
with. When the candidate is 
done modifying their settings 
he or she hits “submit” to 
transmit settings back to RBAS. 

Step 4: RBAS acknowledges the request, 
and updates the member’s preferences 
queue and updates the database. 


Step 5: The system sends a positive 
response acknowledging the changes and 
instructs user to log off and on to view 
the changes. 

AUTERNATE 

COURSES: 

SR Step 2: The system is query results are negative. 

SR Step 3: The system presents and error message informing the candidate 
and asks the user if they would like to personalize their portal. 


AA Step 4: If the candidate provides a positive acknowledgement they 
proceed to step 2 of the Create Personal Portal Content. If not, the 
transaction is cancelled. 

CONCUUSION: 

The candidate updates their settings for their personalized web portal. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Candidate Subsystem 


USE CASE NAME; 

Delete personal web portal content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION; 

This use case describes how a candidate can delete settings for their 
personalized web portal in Reserve Billet Advertisement System. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER; 

The candidate chooses to delete their personal web portal settings. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The candidate selects 
“delete” portal settings from 
menu of choices. 

Step 2: The system queries the database 
for the candidate’s currents settings. 


Step 3; If the candidate has personal 
settings, RBAS displays the query results 
and prompts the user to verify that they 
want to delete these settings. 

Step 4: The candidate 
acknowledges the system 
prompt. 

Step 5: The system deletes the user’s 
personal settings and restores the 
system’s default settings. 

AUTERNATE 

COURSES: 

SR Step 3: The candidate doesn’t have any portal settings and the system 
displays an error message and transaction is canceled. 

CONCUUSION: 

The candidate deletes personal web portal settings. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


Delete Portal Settings Process Model 


Delete 
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Candidate Subsystem 


USE CASE NAME: 

Use External Marine Corps Services 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This Use Case describes how a Candidate can use external links to manage 
their career. 

PRE-CONDITION: 

Candidate has successfully logged onto RBAS. 

TRIGGER: 

Candidate clicks on an external link. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: Candidate actuates an 
external link. 


Step 2: System opens another display 
window. 


Step 3: System opens requested resource. 


ALTERNATE 

COURSES: 


Step 3: System reports error if link is not operational. 


CONCLUSION: 


Candidate has successfully navigated to desired external site. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Use External Resources l^rocess Model 

Request 
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Candidate Subsystem 


USE CASE NAME: 

Participate in community events 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Low 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This Use Case describes how a Candidate can use the community tools 
available in the RBAS system. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

Candidate clicks on community tool of choice. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: Candidate actuates a 
community tool of choice from 
the Candidate Menu. 


Step 2: System opens another display 
window. 


Step 3: System opens requested resource. 


ALTERNATE 

COURSES: 


CONCLUSION: 


When reservist has successfully navigated to desired community resource. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Participate In Community Events Process Model 
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Candidate Subsystem 


USE CASE NAME: 

Search Available Advertisements 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employers 

DESCRIPTION: 

This Use Case describes how a Candidate can search for jobs posted by 
Employers that match their search criteria. 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

Candidate conducts a search of billets. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: Candidate enters search 
criteria into query form and 
clicks “submit”. 

Step 2: System verifies the data entered 
into search form. 


Step 3: If the information is complete, 
the system accepts the request and 
conducts the search. 


Step 4: System displays matching billet 
information to the candidate. 

AUTERNATE 

COURSES: 

SR Step 3: System displays an error screen if no billets match and prompts 
user to correct 

AA Step 4: Candidate reenters data, resubmits and the process begins at 
step #2 of “typical course of events.” 

OR 

SR Step 3: System displays an error screen if information is incomplete and 
prompts user to correct and reenter data. 

AA Step 4: Candidate reenters data, resubmits and the process begins at 
step #2 of “typical course of events.” 

CONCUUSION: 

The candidate is presented with the results of his or her query. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Candidate Subsystem 


USE CASE NAME: 

View applicant pool for an active 
advertisement 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how a candidate can view the current details of an 
active advertisement with respect to other candidates that have applied for a 
billet. 

PRE-CONDITION: 

The candidate is registered Reserve Billet Advertisement System and have 
been assigned the appropriate level of access. 

TRIGGER: 

The candidate clicks on an active advertisement and views the number and 
qualifications of applicants for that particular billet. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: The candidate selects 
“applicants” from an active 
advertisement. 


Step 2: The system will query the 
database to retrieve the applicant queue 
for the selected advertisement. 


Step 3: The system will display all 
activity associated with that particular 
advertisement. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The candidate views activity associated with an advertisement. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Review Application Pool Process Model 
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Candidate Subsystem 


USE CASE NAME: 

Create Reserve Qualification Summary 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This use case describes how a candidate can create an electronic Reserve 
Qualification Summary (RQS). 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The candidate clicks on “Create RQS”. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The candidate selects 
“Create RQS” from main menu. 

Step 2: The system displays RQS with 
data populated from RBAS. 

Step 3: The candidate will 
input his or her information into 
the free form text blocks and 
click “submif ’ when finished. 

Step 4: If data is input correctly, the 
system accepts the RQS and stores it. 

Step 5: The candidate receives 
confirmation that RQS has 
successfully been created. 

Step 6: The system generates leads for 
Employers and Recruiters that have 
subscribed to automated candidate search 
services. 


Step 7: The system generates an email 
for the candidate acknowledging the 
systems acceptance of their RQS. 

AUTERNATE 

COURSES: 


CONCUUSION: 

The candidate successfully creates a RQS. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 

The candidate will not be able to update any personal information directly, 
with the exception of resume remarks on RQS. 

IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Create Resume Process Model 
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Candidate Subsystem 


USE CASE NAME: 

Review Reserve Qualification 

Summary 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how a candidate can review their electronic Reserve 
Qualification Summary (RQS). 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The candidate clicks on “Review RQS”. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: The candidate selects 
“Review RQS” from main 
menu. 


Step 3: The candidate reviews 
the RQS. 


Step 2: The system displays the 
candidate’s RQS with data populated 
from RBAS. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The candidate successfully reviews their RQS. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 
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Candidate Subsystem 


USE CASE NAME: 

Update Reserve Qualification 

Summary 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This use case describes how a candidate can update an electronic Reserve 
Qualification Summary (RQS). 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The candidate clicks on “Update RQS”. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step I: The candidate selects 
“Update RQS” from main 
menu. 

Step 2: The system displays the 
candidate’s RQS with data populated 
from RBAS. 

Step 3: The candidate will 
update his or her information in 
the free form text blocks and 
click “submit” when finished. 

Step 4: If data is input correctly, the 
system accepts the updated RQS 
information and stores it. 

Step 5: The candidate receives 
confirmation that their RQS has 
successfully been updated. 

Step 6: The system generates leads for 
Employers and Recruiters that have 
subscribed to automated candidate search 
services. 


Step 7: The system generates an email 
for the candidate acknowledging the RQS 
update. 

AUTERNATE 

COURSES: 


CONCUUSION: 

The candidate successfully updates their RQS. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 

The candidate will not be able to update any personal information directly, 
with the exception of resume remarks on RQS. 

IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Candidate Subsystem 


USE CASE NAME: 

Delete Reserve Qualification Summary 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Candidate 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This use case describes how a candidate can delete their electronic Reserve 
Qualification Summary (RQS). 

PRE-CONDITION: 

The candidate is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The candidate clicks on “Delete RQS”. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: The candidate selects 
“Delete RQS” from main menu. 


Step 3: The candidate clicks 
“Delete RQS”. 


Step 5: Candidate selects “yes” 
or “no”. 


Step 2: The system displays the 
candidate’s RQS with data populated 
from RBAS. 


Step 4: System prompts candidate “Are 
you sure you want to delete this RQS?” 


Step 6: If “yes” RQS information is 
deleted from RBAS. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The candidate successfully deletes their RQS. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Delete Resume Process Model 
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Candidate Subsystem 


USE CASE NAME; 

Manage Billet Leads 

USE CASE TYPE 

System Analysis 

PRIORITY; 

Medium 

SOURCE; 

Requirement 

PRIMARY BUSINESS 
ACTOR; 

Candidate 

OTHER 

PARTICIPATING 

ACTORS; 

Employer 

OTHER 

INTERESTED 

STAKEHOUDERS; 


DESCRIPTION; 

This Use Case describes how a Candidate can manage all leads that have 
been generated for advertisements that are included in their subscriptions. 

PRE-CONDITION; 

You must have the proper roles to be able to complete this use-case. 

TRIGGER; 

This use case is initiated when a candidate with roles clicks “Manage 

Leads” 

TYPICAU COURSE 

OF EVENTS; 

Actor Action 

System Response 

Step 1: Candidate with roles 
clicks “Manage Leads” 

Step 2: Screen with listing of all current 
leads appears for the candidate to select 
which one to manage. 

Step 3: Candidate clicks on 
appropriate lead to obtain all its 
details. 

Step 4: System displays all details of 
specific lead. 

Step 5: Candidate is given the 
option to update/delete the lead 
or return to the Leads menu. 


AUTERNATE 

COURSES; 


CONCUUSION; 

This use case concludes when the candidate is successfully able to manage 
advertisement leads. 

POST-CONDITION; 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS; 

User must have access to NMCI compliant web browser. 


Candidate Manage Billet Leads Proeess Model 
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APPENDIX C. RECRUITER USE CASES 


Recruiter Subsystem 


USE CASE NAME: 

Search all available billets 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Recruiter 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

DESCRIPTION: 

This Use Case describes how a recruiter can search for billets that match 
their search criteria (MOS, GeoLoc, Dates). 

PRE-CONDITION: 

The PSR is registered in the Reserve Billet Advertisement System and has 
been assigned the appropriate level of access. 

TRIGGER: 

PSR conducts a search of billets. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: PSR enters search 
criteria into query form and 
clicks “submit”. 

Step 2: System verifies the data entered 
into search form. 


Step 3: If the information is complete, 
the system accepts the request and 
conducts the search. 


Step 4: System displays matching billets 
to the PSR. 

AUTERNATE 

COURSES: 

SR Step 3: System displays an error screen if no billets match and prompts 
user to correct 

AA Step 4: PSR reenters data, resubmits and the process begins at step #2 
of “typical course of events.” 

OR 

SR Step 3: System displays an error screen if information is incomplete and 
prompts user to correct and reenter data. 

AA Step 4: PSR reenters data, resubmits and the process begins at step #2 
of “typical course of events.” 

CONCUUSION: 

The PSR is presented with the results of his or her query. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Recruiter Subsystem 


USE CASE NAME: 

Search all available candidates 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Recruiter 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This Use Case describes how a recruiter can search for candidates that 
match their search criteria (MOS, GeoLoc, Dates). 

PRE-CONDITION: 

The recruiter is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

PSR conducts a search of candidates. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1 : Recruiter enters search 
criteria into query form and 
clicks “submit”. 

Step 2: System verifies the data entered 
into search form. 


Step 3: If the information is complete, 
the system accepts the request and 
conducts the search. 


Step 4: System displays matching 
candidates to the recruiter. 

AUTERNATE 

COURSES: 

SR Step 3: System displays an error screen if no candidates match and 
prompts user to correct 

AA Step 4: Recruiter reenters data, resubmits and the process begins at step 
#2 of “typical course of events.” 

OR 

SR Step 3: System displays an error screen if information is incomplete and 
prompts user to correct and reenter data. 

AA Step 4: PSR reenters data, resubmits and the process begins at step #2 
of “typical course of events.” 

CONCUUSION: 

The PSR is presented with the results of his or her query. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Search Candidates Process Model 
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Recruiter Subsystem 


USE CASE NAME: 

Manage candidate leads 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Recruiter 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

OTHER 

INTERESTED 

STAKEHOUDERS: 


DESCRIPTION: 

This Use Case describes how a Recruiter can manage all leads that have 
been generated for billets that are included in their district. 

PRE-CONDITION: 

You must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when a recruiter with roles clicks “Manage Leads” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: Recruiter with roles 
clicks “Manage Leads” 

Step 2: Screen with listing of all current 
leads appears for the recruiter to select 
which one to manage. 

Step 3: Recruiter clicks on 
appropriate lead to obtain all its 
details. 

Step 4: System displays all details of 
specific lead. 

Step 5: Recruiter is given the 
option to update/delete the lead 
or return to the Leads menu. 


AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the recruiter is successfully able to manage 
candidate leads. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


Recruiter Manage Leads Process Model 

Ouer>- All 
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Recruiter Subsystem 


USE CASE NAME: 

View Ad Hoc Report 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Recruiter 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This Use Case describes how a Recruiter generates and views ad hoc 
reports. 

PRE-CONDITION: 

The recruiter is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access 

TRIGGER: 

Recruiter inputs query data into the report input form and hits submit. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The recruiter enters the 
requested dataset into the form 
and clicks the “submit” button. 

Step 2: System verifies completeness of 
data entered into query. 


Step 3: If all required information is 
entered, the system performs the query. 


Step 4: System displays results to 
recruiter. 

AUTERNATE 

COURSES: 

SR Step 3: All the required information not present, error message sent to 
user. 

AA Step 4: The recruiter corrects the error and resubmits. 

SR Step 5: System verifies completeness of data entered into query. 

SR Step 6: If all required information is entered, the system performs the 
query. 

SR Step 7: System displays results to recruiter. 

CONCUUSION: 

The recruiter is presented with report requested. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Recruiter Subsystem 


USE CASE NAME: 

View Vacant Billet Report 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Low 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Recruiter 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This Use Case describes how a Recruiter generates and views the vacant 
billet report. 

PRE-CONDITION: 

The recruiter is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access 

TRIGGER: 

Recruiter enters reports page and clicks on vacant billet report. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: The recruiter enters the 
reports page and clicks on 
vacant billet report. (Recruiter 
will have option to filter 
results) 


Step 2: System queries all current 
advertisements which are currently 
vacant. 


Step 3: System displays results to 
recruiter. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The recruiter is presented with report requested. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Recruiter Vacant Billet Report Process Model 
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Recruiter Subsystem 


USE CASE NAME: 

Create Personal Web Portal Content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Recruiter 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how a Recruiter can create a personalized web portal 
upon initial login to the Reserve Billet Advertisement System. 

PRE-CONDITION: 

The recruiter is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The recruiter subscribes to service via RBAS. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The recruiter logs on to 
RBAS for the first time. 

Step 2: The system prompts the recruiter 
to select what content they want to add to 
their personal portal. The user will be 
provided with a list of alternatives to 
select from. 

Step 3: The recruiter selects the 
services that he or she wants to 
populate their personal portal 
with. When the recruiter is done 
choosing, he or she hits 
“submit” to transmit settings 
back to RBAS. 

Step 4: RBAS acknowledges the request, 
and updates the recruiter’s preferences 
queue and updates the database. 


Step 5: The system sends a positive 
response acknowledging changes and 
instructs user to log off and back on to 
view the changes. 

AUTERNATE 

COURSES: 

None 

CONCUUSION: 

The recruiter personalizes their web portal. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Recruiter Subsystem 


USE CASE NAME: 

Review Personal Web Portal Content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Recruiter 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how a recruiter can review the customizable 
information contained within their personal web portal (ie RSS feeds, 
content) 

PRE-CONDITION: 

The recruiter is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The recruiter reviews their personal settings within their RBAS personal 
portal. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The recruiter selects 
“review” portal settings from 
menu of choices. 

Step 2: The system queries the database 
for the recruiter’s currents settings. 


Step 3: If the recruiter has personal 
settings, RBAS displays the queries 
results. 

AUTERNATE 

COURSES: 

None 

CONCUUSION: 

The recruiter reviews their personal web portal settings. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 

Review Recruiter Portal Settings Process Model 
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Recruiter Subsystem 


USE CASE NAME: 

Update Personal Web Portal Content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Recruiter 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how a recruiter can update the customizable 
information contained within their personal web portal (ie RSS feeds, 
content) 

PRE-CONDITION: 

The recruiter is registered Reserve Billet Advertisement System and has 
been assigned the appropriate level of access. 

TRIGGER: 

The recruiter updates their personal settings within their RBAS personal 
portal. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The recruiter selects 
“update” portal settings from 
menu of choices. 

Step 2: The system queries the database, 
populates the list of alternatives with 
current settings. 


Step 3: The system prompts the recruiter 
to update their selections. 

Step 4: The recruiter selects the 
services that he or she wants to 
populate their personal portal 
with. When the recruiter is done 
modifying their settings he or 
she hits “submit” to transmit 
settings back to RBAS. 

Step 5: RBAS acknowledges the request, 
and updates the recruiter’s preferences 
queue and updates the database. 


Step 6: The system sends a positive 
response acknowledging the changes and 
instructs user to log off and back on to 
view the changes. 

AUTERNATE 

COURSES: 

None 

CONCUUSION: 

The recruiter updates their personal web portal settings. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Recruiter Subsystem 


USE CASE NAME: 

Delete Personal Web Portal Content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Recruiter 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how a recruiter can delete the customizable 
information contained within their personal web portal (ie RSS feeds, 
content) 

PRE-CONDITION: 

The recruiter is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The recruiter deletes their personal settings within their RBAS personal 
portal. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: The recruiter selects 
“delete” portal settings from 
menu of choices. 


Step 4: The recruiter 
acknowledges the system 
prompt. 


Step 2: The system queries the database 
for the recruiter’s currents settings. 


Step 3: If the recruiter has personal 
settings, RBAS displays the query results 
and prompts the user to verify that they 
want to delete these settings. 


Step 5: The system deletes the recruiter’s 
personal settings and restores the 
system’s default settings. 


ALTERNATE 

COURSES: 


SR Step 3: The recruiter does 
displays an error message and 


not have any portal settings and the system 
the transaction is canceled. 


CONCLUSION: 


The recruiter deletes their personal web portal settings. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Delete Recruiter Portal Settings Process Model 
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Recruiter Subsystem 


USE CASE NAME: 

Create Candidate Lead Subscription 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR: 

Recruiter 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This Use Case describes how a Recruiter can create a subscription to 
automatically receive updates (email or notification on portal) if new 
candidates that fit his or her criteria (geo loc, dates, MOS) have recently 
registered, posted new or updated information or deleted items from their 
profile. 

PRE-CONDITION: 

The recruiter is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

This use case is initiated when a recruiter with roles clicks “Create 
Subscription” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: Recruiter with roles 
clicks “Create Subscription” 

Step 2: Screen with subscription criteria 
(MOS, GeoLoc, Dates) appears for 
recruiter to select or input. 

Step 3: Recruiter completes 
form and clicks submit. 

Step 4: The system verifies the 
information. 


Step 5: If the information is correct, the 
system accepts the subscription. 


Step 6: The system places the recruiter 
and their search criteria in its 
subscription queue. 


Step 7: Leads are generated for 
candidates that have subscribed to 
recruiter search services. 


Step 8: The system compares the criteria 
of newly posted, updated or deleted 
candidates versus the criteria posted by 
subscribers. 

AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the recruiter receives a confirmation that the 
subscription has been created successfully. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Recruiter Create Subscription Process Model 
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Recruiter Subsystem 


USE CASE NAME; 

Review Candidate Lead Subscription 

USE CASE TYPE 

System Analysis 

PRIORITY; 

Medium 

SOURCE; 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR; 

Recruiter 

OTHER 

PARTICIPATING 

ACTORS; 


DESCRIPTION; 

This Use Case describes how a recruiter can review their subscriptions 
without making any modifications to them. 

PRE-CONDITION; 

Recruiter must have the proper roles to be able to complete this use-case. 

TRIGGER; 

This use case is initiated when a Recruiter with roles clicks “Review 
Subscriptions” 

TYPICAU COURSE 

OF EVENTS; 

Actor Action 

System Response 

Step 1: Recruiter with roles 
clicks “Review Subscriptions” 

Step 2: The system will query the 
database to retrieve the recruiter’s 
subscription information. 


Step 3; Once an active record is found, 
the system will display the retrieved 
subscription information. 

Step 4: Recruiter can review 
subscription information 


AUTERNATE 

COURSES; 

SR Step 3; The system is unable to locate a subscription for the recruiter. 

SR Step 4; The system displays an error message that informs the recruiter 
that he or she has no active subscriptions. 

CONCUUSION; 

This use case concludes when the recruiter can review their current 
subscription(s). 

POST-CONDITION; 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS; 

User must have access to NMCI compliant web browser. 


Review Subscription Process Model 
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Recruiter Subsystem 


USE CASE NAME: 

Update Candidate Lead Subscription 

USE CASE TYPE 

PRIORITY: 

Medium 

System Analysis 

SOURCE: 

Requirements Analysis 


PRIMARY BUSINESS 
ACTOR: 

Recruiter 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This Use Case describes how a recruiter can update their active 
subscriptions. 

PRE-CONDITION: 

Recruiter must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when a Recruiter with roles clicks “Update 
Subscription” 

TYPICAU COURSE 

Actor Action 

System Response 

OE EVENTS: 

Step 1: Recruiter with roles 
clicks “Update Subscriptions” 

Step 2: The system will query the 
database to retrieve the recruiter’s 
subscription information. 



Step 3: Once an active record is found, 
the system will prompt the recruiter to 
verify if the information retrieved is the 
subscription they want to update. 


Step 4: The recruiter verifies 
the information and 
acknowledges by pressing 
continue. 

Step 5: The system then opens a 
subscription edit window and populates 
the fields with the retrieved information 
and prompts the user to update the 
subscription. 


Step 6: The recruiter updates 
the information and hits 
“submit” when complete. 

Step 7: The system error checks the 
information, if the information is correct 
the update is accepted, acknowledged 
and the database is updated. 



Step 8: The system places the recruiter 
and their search criteria in its 
subscription queue. 



Step 9: Leads are generated for 
candidates that have subscribed to 
recruiter search services. 



Step 10: The system compares the billet 
identifiers of newly posted, updated or 
deleted jobs versus the criteria posted by 
subscribers. 



Step 11: If the search criteria matches, an 
email is generated and sent to the 
recruiter or his portal is updated, (which 
ever method is selected) 

AUTERNATE 

COURSES: 

SR Step 3: The system is unable to locate a subscription for the recruiter. 


SR Step 4: The system displays an error message that informs the recruiter 
that he or she has no active subscriptions. 

CONCUUSION: 

This use case concludes when the recruiter can update their current 
subscription(s). 
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POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


Recruiter Update Subscription Process Model 
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Recruiter Subsystem 


USE CASE NAME: 

Delete Candidate Lead Subscription 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR: 

Reservist 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This Use Case describes how a Recruiter can delete an active subscription. 

PRE-CONDITION: 

You must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when a Recruiter with roles clicks “Delete 
Subscription” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The recruiter selects 
“delete” subscription from 
menu of choices. 

Step 2: The system will query the 
database to retrieve the recruiter’s 
subscription information. 


Step 3: Once an active record is found, 
the system will prompt the recruiter to 
verify if the information retrieved is the 
subscription they want deleted. 

Step 4: The recruiter verifies 
the information and 
acknowledges by pressing 
continue. 

Step 5: The system then prompts the 
recruiter if they are certain they want to 
cancel this subscription. 

Step 6: The recruiter 
acknowledges his or her 
approval by clicking “yes” 

Step 7: The system receives the response 
and deletes the subscription from the 
database 


Step 8: A success message is generated 
and displayed to the recruiter. 

AUTERNATE 

COURSES: 

SR Step 3: The system is unable to locate a subscription for the recruiter. 

SR Step 4: The system displays an error message that informs the recruiter 
that he or she has no active subscriptions. 

AA Step 6: The recruiter declines to delete subscription. 

SR Step 7: The system acknowledges the negative response and deletes the 
transaction. 

SR Step 8: The system displays successful cancellation message to user. 

CONCUUSION: 

This use case concludes when the recruiter receives a confirmation that the 
subscription was successfully deleted. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Recruiter Delete Subscription Process Model 
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Recruiter Subsystem 
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APPENDIX D. MANAGER USE CASES 


Management Subsystem 


USE CASE NAME: 

Create Roles For Users or Groups of 
RBAS 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

System Requirement 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This Use Case describes how system managers control the access and 
privileges of system users by creating individual and group accounts. 

PRE-CONDITION: 

The System Manager is registered in the Reserve Billet Advertisement 

System and has been assigned the appropriate level of access. 

TRIGGER: 

The Use Case is initiated when the System Manager creates a new user. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The System Manager 
role request queue has pending 
requests. System Manager 
selects “Assign Roles” from the 
management portal. 

Step 2: The system auto populates a user 
input form with the values in RBAS and 
prompts the System Administrator to 
assign the user or groups roles and rights. 

Step 3: The System Manager 
selects the appropriate roles and 
responsibilities and submits 
them to RBAS. 

Step 4: The system verifies the 
information inputted into the form. 


Step 5: The system accepts the new roles 
assignment and stores it in the database. 


Step 6: The system generates an email 
and broadcast for the user who was 
granted rights to the system, which 
includes all of their logon information 
and access privileges. 


Step 7: The system generates a success 
message for the System Manager and 
prompts the user to add another group or 
user. 

Step 8: The user responds 
either negatively or positively 
to the prompt. If positive the 
process starts over at Step 1 
else the system exits the 
application. 
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ALTERNATE 

COURSES; 

SR Step 3: All the required information not present, error message sent to 
user. 

AA Step 4: System Manager corrects the error and resubmits. 

Return to step 2 of the “Typical Course of Events” 

OR 

AA Step 5: The System Manager responds negatively to system prompt and 
request is canceled. 

CONCLUSION: 

A new group or user is created. 

POST-CONDITION: 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 
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Management Subsystem 


USE CASE NAME: 

Review Roles For Users or Groups of 
RBAS 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

System Requirement 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This Use Case describes how a System Manager can review the roles and 
rights assigned roles to a user or a group. 

PRE-CONDITION: 

The System Manager is registered in the Reserve Billet Advertisement 

System and has been assigned the appropriate level of access. 

TRIGGER: 

The Use Case is initiated when the System Manager chooses to review user 
or group’s rights and responsibilities. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step I: The System Manager 
selects a user or group and then 
selects “review privileges” 
from the management portal. 

Step 2: The system auto populates a 
user/group report with the current roles 
and rights value and then ask the user if 
he or she wishes to view another. 

Step 3: The System Manager 
views the data, and either 
positively or negatively 
responds to the prompt by 
selecting “yes” or “no”. If the 
System Manager selects yes the 
process begins over at Step 1 
else the system exits to the 
homepage. 


AUTERNATE 

COURSES: 

SR Step 3: All the required information not present, error message sent to 
user. 

AA Step 4: System Manager corrects the error and resubmits. 

Return to step 2 of the “Typical Course of Events” 

OR 

AA Step 5: The System Manager responds negatively to system prompt and 
request is canceled. 

CONCUUSION: 

The System Manager views the roles and rights of a group or user. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 
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Management Subsystem 


USE CASE NAME: 

Update User or Group Roles and 

Rights 

USE CASE TYPE 

PRIORITY: 

High 

System Analysis 

SOURCE: 

System Requirement 


PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This Use Case describes how a System Manager can update the roles and 
rights assigned roles to a user or a group. 

PRE-CONDITION: 

The System Manager is registered in the Reserve Billet Advertisement 

System and has been assigned the appropriate level of access. 

TRIGGER: 

The Use Case is initiated when the System Manager chooses to update a 
user or group’s rights and responsibilities. 

TYPICAU COURSE 

Actor Action 

System Response 

OF EVENTS: 

Step I: The System Manager 
selects a user or group and then 
selects “update privileges” from 
the management portal. 

Step 2: The system auto populates a user 
or group edit form with the values stored 
in the database and prompts the System 
Administrator to make any changes the 
user or groups roles and rights that they 
desired. 


Step 3: The System Manager 
selects the appropriate roles and 
responsibilities and submits 
them to RBAS. 

Step 4: The system verifies the 
information inputted into the form. 



Step 5: The system accepts the changes 
and stores it in the database. 



Step 6: The system generates an email 
and broadcast for the user which includes 
all the changes that were made to the 
account. 



Step 7: The system generates a success 
message for the System Administrator 
and asks the user if he or she wish to edit 
another group or user. 


Step 8: The user responds 
either negatively or positively 
to the prompt. If positive the 
process starts over at Step 1 
else the system exits the 
application. 


AUTERNATE 

COURSES: 

SR Step 3: All the required information not present, error message sent to 
user. 


AA Step 4: System Manager corrects the error and resubmits. 


Return to step 2 of the “Typical Course of Events” 


OR 


AA Step 5: The System Manager responds negatively to system prompt and 
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request is canceled. 

CONCLUSION; 

The System Manager makes the desired changes to the roles and rights of a 
group or user. 

POST-CONDITION: 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 
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Management Subsystem 


USE CASE NAME: 

Delete User or Group Roles and Rights 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirement Analysis 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Employer 

Recruiter 

DESCRIPTION: 

This Use Case describes how a System Manager deletes a user access to the 
system. 

PRE-CONDITION: 

The System Manager is registered in the Reserve Billet Advertisement 

System and has been assigned the appropriate level of access. 

TRIGGER: 

The System Manager selects a user or group whose rights they want to 
delete. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The actor selects a user 
or group whose rights are going 
to be deleted and then selects 
“delete user” from the 
management portal. 

Step 2: The system queries the database 
and auto populates a delete user input 
form and prompts the System 
Administrator to verify that they want to 
remove this user or group from the 
system. 

Step 3: The user responds 
either negatively or positively 
to the prompt by clicking on 
“yes” or “no”. 

Step 3: If the System Manager positively 
responds then the system will honor the 
delete request of the user or group and 
update the database. 


Step 4: The system generates a success 
message for the System Administrator. 


Step 6: The system generates an email to 
the user and/or group and informs them 
of their privileges being revoked. 

AUTERNATE 

COURSES: 

Step 3: If the System Manager negatively responds to the acknowledgement 
prompt the transaction will be cancelled. 

CONCUUSION: 

The user and/or group rights were revoked. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 
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Management Subsystem 


USE CASE NAME: 

Create Personal Content for 

Management and Site Portals 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employers 

Recruiters 

Candidates 

DESCRIPTION: 

This use case describes how a System Manager can create content for the 
management web portal as well as control the core content for the entire 
RBAS site. 

PRE-CONDITION: 

The System Manager is registered in the Reserve Billet Advertisement 

System and has been assigned the appropriate level of access. 

TRIGGER: 

The System Manager creates site wide content or management portal 
settings in RBAS. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step I: The System Manager 
logons to RBAS. 

Step 2: The system prompts the user to 
select what content they want included in 
the management portal or site core portal. 
The user will be provided with a list of 
alternative to select from. 

Step 3: The System Manager 
selects the services that he or 
she wants to populate the 
management or core site portal 
with. When the System 

Manager is done selecting 
content he or she clicks 
“submit” to transmit settings 
back to RBAS. 

Step 4: RBAS acknowledges the request, 
and updates the system manager’s 
preferences queue and updates the 
database. 


Step 5: The system sends a positive 
response acknowledging changes and 
instructs user to log on and off to view 
the changes. 

AUTERNATE 

COURSES: 

None 

CONCUUSION: 

The system manager creates the attributes for the management and/or the 
site core web portal. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 
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Management Subsystem 


USE CASE NAME: 

Review Management and Site Web 
Portal Content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This use case describes how a System Manager can review settings for both 
the Managerial and Site web portal for the Reserve Billet Advertisement 
System. 

PRE-CONDITION: 

The System Manager is registered in the Reserve Billet Advertisement 

System and has been assigned the appropriate level of access. 

TRIGGER: 

The System Manager reviews Managerial and/or Site web portal settings in 
RBAS. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step I: The system manager 
selects “view” Managerial web 
portal settings or “view” Site 
web portal settings from menu 
of choices. 

Step 2: The system queries the database 
for the System Manager’s current 
settings. 


Step 3: RBAS displays the queries 
results. 

AUTERNATE 

COURSES: 

SR Step 3; If the RBAS’s settings have not been modified from the default 
values the system displays an error message. 


CONCUUSION: 

The System Manager reviews either or both the Managerial and/or the Site 
web portal settings. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 
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Management Subsystem 


USE CASE NAME: 

Update Personal Content for 
Management and Site Portals 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This use case describes how a System Manager can update their 
personalized web portal as well as the core portal attributes for the entire 
Reserve Billet Advertisement System. 

PRE-CONDITION: 

The System Manager is registered Reserve Billet Advertisement System and 
have been assigned the appropriate level of access. 

TRIGGER: 

The System Manager chooses to update their personal web portal content 
site content in RBAS. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step I: The system manager 
selects “update” portal settings 
from menu of choices. 

Step 2: The system queries the database, 
populates the list of alternative with 
current settings. 


Step 3: The system prompts the system 
manager to update their selections. 

Step 3: The system manager 
selects the services that he or 
she wants to populate their 
personal portal with. When the 
user is done modifying their 
settings he or she hits “submit” 
to transmit settings back to 
RBAS. 

Step 4: RBAS acknowledges the request, 
and updates the member’s preferences 
queue and updates the database. 


Step 5: The system sends a positive 
response acknowledging the changes and 
instructs user to log on and off to view 
the changes. 

AUTERNATE 

COURSES: 

SR Step 2: The system is query results are negative. 

SR Step 3: The system presents and error message informing the candidate 
and asks the user if they would like to personalize their portal. 


AA Step 4: If the System Manager provides a positive acknowledgement 
they proceed to step 2 of the Create Personal Portal Content. If not, the 
transaction is cancelled. 

CONCUUSION: 

The System Manager updates their settings for their personalized web portal 
or the settings for the site web portal are updated. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 
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Manager Subsystem 


USE CASE NAME: 

Delete Personal Content for 

Management and Site Portals 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This use case describes how a System Manager can delete settings for the 
Management or Site web portal for the Reserve Billet Advertisement 

System. 

PRE-CONDITION: 

The System Manager is registered Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The System Manager deletes content from either the Management or Site 
web portal. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step I: The System Manager 
selects “delete” management 
portal settings or “delete” site 
portal settings from menu of 
choices. 

Step 2: The system queries the database 
for the System Manager’s current 
settings. 


Step 3: RBAS displays the query results 
and prompts the user to verify that they 
want to delete the settings. 

Step 4: The system manager 
acknowledges the system 
prompt. 

Step 5: The system deletes the user’s 
personal settings and restores the 
system’s default settings. 

AUTERNATE 

COURSES: 

SR Step 3: RBAS is at the default values of the system therefore the System 
Manager doesn’t have any portal settings to delete. 

SR Step 4: The system displays an error message and transaction is 
canceled. 

CONCUUSION: 

The candidate deletes personal web portal settings. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 
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Management Subsystem 


USE CASE NAME: 

Generate Detailed User Report 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This Use Case describes how a System Manager generates a detailed report 
on an individual user. 

PRE-CONDITION: 

System Manager has applied for and received access to the system with 
appropriate permissions. 

TRIGGER: 

System Manager identifies a user of interest and queries the system by 
hitting submit. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The System Manager 
selects “detailed user report” 
from the management portal 
and clicks submit. 

Step 2: System queries the database for 
the user of interest and retrieves the data 
requested. 


Step 3: System displays results to the 
System Manager. 


Step 4: The system asks the user if he or 
she wishes to view another user’s 
information. 

Step 5: The System Manager 
responds positively the user 
clicks “yes’, the system 
manager selects another user 
and the process starts over else 
the transaction is complete. 


AUTERNATE 

COURSES: 

SR Step 3: The user doesn’t exist in the database and a error message is 
displayed. 

AA Step 4: The System Manager corrects the error and resubmits. 

SR Step 5: System verifies completeness of data entered into query. 

SR Step 6: If all required information is entered, the system performs the 
query. 

SR Step 7: System displays results. 

CONCUUSION: 

The System Manager is presented with report requested. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

The System Manager has access and the roles required for use of RDOL. 
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Management Subsystem 


USE CASE NAME: 

Generate System Usage Report 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This Use Case describes how a System Manager generates a report that 
tracks the use of the RBAS system. 

PRE-CONDITION: 

System Manager has applied for and received access to the system with 
appropriate permissions. 

TRIGGER: 

System queries the system for use rates. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: Manager selects 
“system usage report” from the 
management portal and clicks 
submit. 


Step 5: If the System Manager 
responds positively the user 
clicks “yes’, the system 
manager is provided with a list 
of alternatives and the process 
starts over, else the transaction 
is complete. 


Step 2: System queries the database and 
retrieves the data requested. 


Step 3: System displays results to the 
System Manager. 


Step 4: The system asks the user if they 
wish to generate another use. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The System Manager is presented with report requested. 


POST-CONDITION: 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


The System Manager has access and the roles required for use of RDOL. 


System Usage Report Proeess Model 




Manager 
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Management Subsystem 


USE CASE NAME: 

Generate User Overview Report 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This Use Case describes how a System Manager generates a report that 
displays all the users of a specific group or category that is registered in the 
RBAS system. 

PRE-CONDITION: 

System Manager has applied for and received access to the system with 
appropriate permissions. 

TRIGGER: 

System Manager identifies a category or group of users of interest and 
queries the system by hitting submit. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step I: After selecting the 
group or category of interest the 
System Manager selects “user 
category report” from the 
management portal and clicks 
submit. 

Step 2: System queries the database for 
the group or category of users of interest 
and retrieves the data requested. 


Step 3: System displays results to the 
System Manager. 


Step 4: The system asks the user if he or 
she wishes to view another group or 
category of users. 

Step 5: If the System Manager 
responds positively the user 
clicks “yes’, the system 
manager selects another group 
or category of users and the 
process starts over, else the 
transaction is complete. 


AUTERNATE 

COURSES: 

SR Step 3: The group or category of users doesn’t exist in the database and 
an error message is displayed. 

AA Step 4: The System Manager corrects the error and resubmits. 

SR Step 5: System verifies completeness of data entered into query. 

SR Step 6: If all required information is entered, the system performs the 
query. 

SR Step 7: System displays results to the Manager. 

CONCUUSION: 

The System Manager is presented with report requested. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 



200 




























ASSUMPTIONS: 


The System Manager has access and the roles required for use of RDOL. 

User Report Proeess Model 
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Management Subsystem 


USE CASE NAME: 

Ensure all form input data is valid and 
complete 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

System Requirement 

PRIMARY BUSINESS 
ACTOR 

System 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

System Manager 

DESCRIPTION: 

This Use Case describes how the RBAS system automatically checks all 
input for completeness and accuracy. 

PRE-CONDITION: 

A user has inputted information into an input form for RBAS. 

TRIGGER: 

The Use Case is initiated when user submits information via an input form. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step 1: A user submits 
information via an input form 
by hitting “submit”. 

Step 2: The system uses defined business 
rules to verify that the input submitted is 
complete and accurate. This includes 
checking for missing information as well 
as for incorrectly formatted data. 


Step 3: The system acknowledges 
validity of input and stores the data in the 
database. 

AUTERNATE 

COURSES: 

SR Step 3: All the required information not present, error message sent to 
user. 

AA Step 4: The user corrects the error and resubmits. 

Return to step 2 of the “Typical Course of Events” 

CONCUUSION: 

The user submits complete and accurate data into an input form 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Manager Subsystem 


USE CASE NAME: 

Automated Update of Candidate Table 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

System 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

MCTFS 

DESCRIPTION: 

This use case describes how a candidate’s personal information gets 
populated from MCTFS. 

PRE-CONDITION: 


TRIGGER: 

This event is a temporal trigger that occurs twice weekly (nominally). 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: Temporal event occurs 

Step 1: The system queries records that 
are currently registered in RBAS. 


Step 2: Most recent MCTFS data is then 
queried for those records. 


Step 3: System then compares actual 
data with updated data. 


Step 4: The two datasets are compared 
for changes. 


Step 5: If system detects changes in data, 
RBAS candidate table is updated with 
new information. 

AUTERNATE 

COURSES: 

SR Step 2: If MCTFS is unavailable at runtime, error message will be 
displayed to system manager. 

CONCUUSION: 

The candidate table information is updated. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

MCTFS is functioning properly. 
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Management Subsystem 


USE CASE NAME: 

Automated Update of MOS Table 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

System 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

MCTFS 

DESCRIPTION: 

This use case describes how the MOS table gets populated from MCTFS. 

PRE-CONDITION: 


TRIGGER: 

This event is a temporal trigger that occurs quarterly (nominally). 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step 1: Temporal event occurs 

Step 1: The system queries MOS table 
resident in RBAS. 


Step 2: Most recent MCTFS MOS 
information is queried. 


Step 3: System then compares actual 
data with updated data. 


Step 4: The two datasets are compared 
for changes. 


Step 5: If system detects changes in data, 
RBAS MOS table is updated with new 
information. 

AUTERNATE 

COURSES: 

SR Step 2: If MCTFS is unavailable at runtime, error message will be 
displayed to system manager. 

CONCUUSION: 

The MOS table information is updated. 

POST-CONDITION: 


BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

MCTFS is functioning properly. 
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Management Subsystem 


USE CASE NAME; 

Ensure that user credentials are verified 
by use of CAC or strong password 
during login process 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 

System 


ACTOR 



PRIMARY SYSTEM 



ACTOR 



OTHER 

Employers 


PARTICIPATING 

Recruiters 


ACTORS: 

Candidates 



Managers 



DESCRIPTION; 


This use case describes the system actions performed when a user logons to 
the system. Credentials will be verified with a Common Access Card 
(CAC) or strong password. 


PRE-CONDITION: 


TRIGGER: 


A user attempts to logon to RBAS. 


TYPICAL COURSE 
OE EVENTS: 


Actor Action 


Step 1; User attempts to logon 
to the RBAS system with either 
a Common Access Card (CAC) 
or Strong Password. 


Step 3; User is successfully 
logged on to RBAS. 


System Response 


Step 2: Credentials of user are validated. 


ALTERNATE 

COURSES: 


SR Step 4: Incorrect password or invalid CAC is identified to user. 

AA Step 3: User reattempts to login with correct password/valid CAC. 


CONCLUSION: 


System validates user for his/her credentials. 


POST-CONDITION: 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User Validation Process Model 


User Attempts 
to Luuin 

CAC PWD" 

, Requested 


Manager 


Credentials 
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Service 
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Management Subsystem 


USE CASE NAME: 

Manage Trouble Call Queue 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements Analysis 

PRIMARY BUSINESS 
ACTOR 

System Manager 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Employers 

Recruiters 

Candidates 

DESCRIPTION: 

This Use Case describes how managers will be able to view and manage all 
trouble calls submitted by users of the system. 

PRE-CONDITION: 

An end user has submitted a trouble ticket. 

TRIGGER: 

System manager clicks “manage trouble tickets”. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1; System manager clicks 
“manage trouble tickets”. 


Step 3: System manager takes 
necessary action to resolve 
trouble ticket. 


Step 4: System manager deletes 
tickets that have been resolved. 


Step 2: System displays listing of all 
trouble tickets in managers queue. 


Step 5: System updates database to 
remove resolved trouble tickets. 


ALTERNATE 

COURSES: 


CONCLUSION: 


System manager successfully manages tickets in trouble call queue. 


POST-CONDITION: 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


Manager Manage Trouble Call Queue Process Model 
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APPENDIX E. EMPLOYER USE CASES 


Employer Subsystem 


USE CASE NAME: 

Create Advertisement 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This use-case describes the action of manually inputting a new 
billet/advertisement into the system to be viewed by potential candidates. 

PRE-CONDITION: 

Employer must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when an Employer with roles clicks “Create 
Advertisement” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: Employer with roles 
clicks “Create Advertisement” 

Step 2: Screen with blank advertisement 
template appears for employer to enter 
information about billet. 

Step 3: Employer completes 
form and clicks “submit” to 
input information into table. 

Step 4: Inputs are validated on client side 
for correct type. 


Step 5: Inputs are added to billet table. 

Step 6: Employer receives 
message that billet has been 
successfully added. 


Step 7: Employer is provided 
the option to add another billet, 
or to return to the main menu. 



Step 8: System generates email to all 
subscribers with ties to this billet. 

AUTERNATE 

COURSES: 

On Step 6, if there is any error in adding the record to the table, a message 
will display that billet was NOT added. 

CONCUUSION: 

This use case concludes when the employer receives a confirmation that the 
billet was successfully entered. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME; 

Review Advertisement 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION; 

This use-case describes the action of reviewing a manually inputted 
billet/advertisement in the system. 

PRE-CONDITION; 

Employer must have the proper roles to be able to complete this use-case. 

TRIGGER; 

This use case is initiated when an Employer with roles clicks “Review 
Advertisement” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: Employer with roles 
clicks “Review Advertisement” 

Step 2: Screen with listing of all current 
advertisements appears for the employer 
to select which one to review. 

Step 3: Employer selects which 
billet to review 

Step 4: Details of selected billet are 
displayed. 


Step 5: Employer is given the option to 
“Update” billet/advertisement or return to 
previous page. 

AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the employer can view the details of a 
requested billet. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME: 

Update Advertisement 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Reservist 

Recruiter 

DESCRIPTION: 

This use-case describes the action of updating a manually inputted 
billet/advertisement in the system. 

PRE-CONDITION: 

Employer must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when an Employer with roles clicks “Update 
Advertisement” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: Employer with roles 
clicks “Update Advertisement” 

Step 2: Screen with listing of all current 
advertisements appears for the employer 
to select which one to update. 

Step 3: Employer selects which 
billet to update. 

Step 4: System displays all billet 
information from billet table. 

Step 5: Employer makes 
necessary updates to billet 
fields. 

Step 6: System validates information on 
client side and updates billet table. 

Step 7: Employer receives 
confirmation on screen that the 
billet was updated. 

Step 8: System generates email to all 
subscribers with ties to this billet. 

AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the employer receives confirmation that the 
billet being edited was updated. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME; 

Delete Advertisement 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Reservist 

Recruiter 

DESCRIPTION; 

This use-case describes the action of deleting a manually inputted 
billet/advertisement from the system. 

PRE-CONDITION; 

Employer must have the proper roles to be able to complete this use-case. 

TRIGGER; 

This use case is initiated when an Employer with roles clicks “Delete 
Advertisement” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: Employer with roles 
clicks “Delete Advertisement” 

Step 2: Screen with listing of all current 
advertisements appears for the employer 
to select. 

Step 3: Employer selects 
appropriate “check boxes” and 
presses delete button. 

Step 4: Window asking “Are you sure?” 
you want to delete the following billet(s) 
is displayed. 

Step 5: Employer checks yes or 
no. 

Step 6: Billet(s) is/are deleted from the 
billet table. 

Step 7 : Employer receives 
message that billet(s) has been 
successfully deleted. 



Step 8: System generates email to all 
subscribers with ties to this billet. 

AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the employer receives a confirmation that the 
billet was successfully deleted. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


Delete Advertisement Process Model 
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Employer Module 


USE CASE NAME: 

Create Automated Advertisement 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer System 

OTHER 

PARTICIPATING 

ACTORS: 

External Data Sources (MCTES, TESMS) 

Recruiter 

Candidate 

DESCRIPTION: 

This use case describes how the system generates billet advertisements 
automatically by comparing MCTES O/H data versus T/O data. 

PRE-CONDITION: 

External data sources (MCTES/TESMS) must be functioning correctly. 

TRIGGER: 

This use case is initiated temporally (weekly) at a specified time. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: System initiates 
transaction at specified time to 
automatically generate 
advertisements. 

Step 2: System queries MCTES for on 
hand strength by Reporting Unit Code 
(RUC). 


Step 3: System queries TESMS for billet 
structure listing by RUC. 


Step 4: MCTES and TESMS data are 
compared against one another to 
determine what billets are vacant, as well 
as calculated losses (Pending EAS, 

Transfer to EMCR) 


Step 5: Automated Advertisements are 
generated for current/future vacant 
billets. 


Step 6: Notification (emaiEportal) is 
delivered to each Employer telling them 
new advertisements have been generated. 

Step 7 : Employer has 7 days to 
validate system generated 
billets prior to them 
automatically posting to RDOL. 


AUTERNATE 

COURSES: 

Alternatively, this report could query data strictly based off of Billet 
Identification Code, if it were tied in MCTES to a Marine’s SSN. 

CONCUUSION: 

This use case concludes when the employer receives a confirmation that the 
automated billets were successfully created. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Module 


USE CASE NAME: 

Create subscription to automated 
candidate search services 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This Use Case describes how an Employer can create a subscription to 
automatically receive updates (email or notification on portal) if new 
candidates that fit his or her criteria (geo loc, dates, MOS) have recently 
registered, posted new or updated information or deleted items from their 
profile. 

PRE-CONDITION: 

The employer is registered Reserve Billet Advertisement System and has 
been assigned the appropriate level of access. 

TRIGGER: 

This use case is initiated when an Employer with roles clicks “Create 
Subscription” 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step I: Employer with roles 
clicks “Create Subscription” 

Step 2: Screen with subscription criteria 
(MOS, GeoLoc, Dates) appears for 
employer to select or input. 

Step 3: Employer completes 
form and clicks submit. 

Step 4: The system verifies the 
information. 


Step 5: If the information is correct, the 
system accepts the subscription. 


Step 6: The system places the employer 
and their search criteria in its 
subscription queue. 


Step 7: Leads are generated for 
candidates that have subscribed to 
employer search services. 


Step 8: The system compares the criteria 
of newly posted, updated or deleted 
candidates versus the criteria posted by 
subscribers. 

AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the employer receives a confirmation that the 
subscription has been created successfully. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME; 

Review subscription to automated 
candidate search services 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION; 

This Use Case describes how an employer can review their subscriptions 
without making any modifications to them. 

PRE-CONDITION; 

Employer must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when an Employer with roles clicks “Review 
Subscription” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step I: Employer with roles 
clicks “Review Subscriptions” 

Step 2: The system will query the 
database to retrieve the employer’s 
subscription information. 


Step 3: Once an active record is found, 
the system will display the retrieved 
subscription information. 

AUTERNATE 

COURSES: 

SR Step 3; The system is unable to locate a subscription for the employer. 

SR Step 4: The system displays an error message that informs the employer 
that he or she has no active subscriptions. 

CONCUUSION: 

This use case concludes when the employer can review their current 
subscription(s). 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


Review Subscription Process Model 
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Employer Subsystem 


USE CASE NAME: 

Update subscription to automated 
candidate search services 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This Use Case describes how an employer can update their active 
subscriptions. 

PRE-CONDITION: 

Employer must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when an Employer with roles clicks “Update 
Subscription” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: Employer with roles 
clicks “Update Subscriptions” 

Step 2: The system will query the 
database to retrieve the employer’s 
subscription information. 


Step 3: Once an active record is found, 
the system will prompt the employer to 
verify if the information retrieved is the 
subscription they want to update. 

Step 4: The employer verifies 
the information and 
acknowledges by pressing 
continue. 

Step 5: The system then opens a 
subscription edit window and populates 
the fields with the retrieved information 
and prompts the user to update the 
subscription. 

Step 6: The employer updates 
the information and hits 
“submit” when complete. 

Step 7: The system error checks the 
information, if the information is correct 
the update is accepted, acknowledged 
and the database is updated. 


Step 8: The system places the employer 
and their search criteria in its 
subscription queue. 


Step 9: Leads are generated for 
candidates that have subscribed to 
employer search services. 


Step 10: The system compares the billet 
identifiers of newly posted, updated or 
deleted jobs versus the criteria posted by 
subscribers. 


Step 11: If the search criteria matches, an 
email is generated and sent to the 
employer or his portal is updated, (which 
ever method is selected) 

AUTERNATE 

COURSES: 

SR Step 3: The system is unable to locate a subscription for the employer. 
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SR Step 4: The system displays an error message that informs the employer 
that he or she has no active subscriptions. 

CONCLUSION: 

This use case concludes when the employer can review their current 
subscription(s). 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


Employer Update Subscription Process Model 
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Employer Subsystem 


USE CASE NAME: 

Delete subscription to automated 
candidate search services 

USE CASE TYPE 

PRIORITY: 

Medium 

System Analysis 

SOURCE: 

Requirement 


PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This Use Case describes how an Employer can delete an active subscription. 

PRE-CONDITION: 

You must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when an 
Subscription” 

Employer with roles clicks “Delete 

TYPICAU COURSE 

Actor Action 

System Response 

OF EVENTS: 

Step I: The employer selects 
“delete” subscription from 
menu of choices. 

Step 2: The system will query the 
database to retrieve the employer’s 
subscription information. 



Step 3: Once an active record is found, 
the system will prompt the employer to 
verify if the information retrieved is the 
subscription they want deleted. 


Step 4: The employer verifies 
the information and 
acknowledges by pressing 
continue. 

Step 5: The system then prompts the 
employer if they are certain they want to 
cancel this subscription. 


Step 6: The employer 
acknowledges his or her 
approval by clicking “yes” 

Step 7: The system receives the response 
and deletes the subscription from the 
database 



Step 8: A success message is generated 
and displayed to the employer. 

AUTERNATE 

COURSES: 

SR Step 3: The system is unable to locate a subscription for the employer. 


SR Step 4: The system displays an error message that informs the employer 
that he or she has no active subscriptions. 


AA Step 6: The employer declines to delete subscription. 


SR Step 7: The system acknowledges the negative response and deletes the 
transaction. 


SR Step 8: The system display successful cancellation message to user. 

CONCUUSION: 

This use case concludes when the employer receives a confirmation that the 
subscription was successfully deleted. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME; 

View current application pool 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Low 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION; 

This use case describes how an employer can view all leads/applications that 
have been submitted for billets in their purview. 

PRE-CONDITION; 

Billet/Advertisement must have had at least one application. 

TRIGGER; 

This use case is initiated when an Employer with roles clicks “View current 
applications” 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step 1: The employer selects 
“applicants” from an active 
advertisement. 

Step 2: The system will query the 
database to retrieve the applicant queue 
for the selected advertisement. 


Step 3: The system will display all 
activity associated with that particular 
advertisement. 

AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the employer can view all current applications 
that are pertinent to his/her BIC/RUC listings. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


View Candidate Pool Process Model 
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Employer Subsystem 


USE CASE NAME: 

Verify validity of automated billet 
generation 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

System Requirement 

PRIMARY BUSINESS 
ACTOR 

Employer 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Recruiter 

Candidate 

DESCRIPTION: 

This Use Case describes how Employers verify the billets generated 
automatically by the RBAS system. 

PRE-CONDITION: 

The Employer is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The Use Case is initiated when the RBAS system notifies the Employer that 
new billets generated automatically are waiting in the approval queue. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 2: The Employer selects 
“review new billets 
advertisements” from their 
portal. 

Step 1: The system sends an alert and an 
email to the employer informing them 
that new billets are in the approval queue. 

Step 3: The Employer views 
the new billet advertisements in 
the queue for validity and 
approves the billet by selecting 
“accept” or by disapproving 
them by selecting “reject”. 

Step 4: The system publishes the 
advertisement if it is accepted by the 
reviewing authority. If the billet is 
rejected it is forwarded to the RUC 
manager. 


Step 5: The system sends notifications 
to all users that have signed up to receive 
billet notifications. 

AUTERNATE 

COURSES: 


CONCUUSION: 

The Employer approves advertisements that were generated automatically 
by the system. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME: 

Manually search all Candidates by 
avenue of interest (MOS/Dates). 

USE CASE TYPE 

System Analysis 

PRIORITY: 

High 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This Use Case describes how an Employer can search for interested 
Candidates that match their search criteria. 

PRE-CONDITION: 

You must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when an Employer with roles clicks “Hire 

Candidate” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step I: Employer enters search 
criteria into query form and 
clicks “submit”. 

Step 2: System verifies the data entered 
into search form. 


Step 3: If the information is complete, 
the system accepts the request and 
conducts the search. 


Step 4: System displays listing of 
candidates matching search criteria. 

Step 5: Employer can then 
click on each candidate to get 
more details (resume). 


AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the employer inputs search criteria and 
receives an accurate listing of candidates meeting those criteria. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


Search Candidates Process Model 
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Employer Subsystem 


USE CASE NAME: 

Hire Candidate 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This use case describes how an employer selects a particular candidate for a 
billet. 

PRE-CONDITION: 

You must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when an Employer with roles clicks “Hire 

Candidate” 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1; Employer with roles 
clicks “Hire Candidate” 

Step 2: Screen appears with listing of all 
applicants for a particular billet. 

Step 3: Employer places check 
box next to candidate to hire. 

Step 4: Confirmation (Are you sure you 
want to hire Candidate XXX for BIC 
XXX?). 


Step 5: Once approved, system sends 
notifications (email/portal) to candidate 
that was selected and candidates not 
selected. 


Step 6: System generates notification to 
all subscribers with ties to this billet. 

AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the employer receives a confirmation that 
candidate was hired and successfully notified. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME: 

Reject Candidate 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This use case describes how an employer rejects a particular candidate for a 
billet. 

PRE-CONDITION: 

You must have the proper roles to be able to complete this use-case. 

TRIGGER: 

This use case is initiated when an Employer with roles clicks “Hire 

Candidate” 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step 1: Employer with roles 
clicks “Hire Candidate” 

Step 2: Screen appears with listing of all 
applicants for a particular billet. 

Step 3: Employer places check 
box next to candidate to hire. 

Step 4: Confirmation (Are you sure you 
want to hire Candidate XXX for BIC 
XXX?). 


Step 5: Once approved system sends 
notifications (email/portal) to candidate 
that was selected and candidates not 
selected. 


Step 6: System generates notification to 
all subscribers with ties to this billet. 

AUTERNATE 

COURSES: 

This process is conducted simultaneously with “Hire Candidate”. Upon a 
candidate being selected and hired for a billet, all other candidates are 
rejected. 

CONCUUSION: 

This use case concludes when the employer receives a confirmation that 
candidate was hired and candidates which were not hired were successfully 
notified. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME: 

Communicate with candidate pool 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This use case describes how an Employer can conduct mass communication 
with all candidates applying for a specific billet. 

PRE-CONDITION: 

Billet must have at least one applicant to create an applicant pool 

TRIGGER: 

This use case is initiated when an Employer with roles clicks “Contact 
applicant pool” for a specific billet. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step 1: The employer selects 
“applicants” from an active 
advertisement. 

Step 2: The system will query the 
database to retrieve the applicant queue 
for the selected advertisement. 

Step 3: The employer selects 
“contact all applicants” for 
specified billet. 

Step 4: The system will bring up a 
subject and free text form box for 
information to be entered. 

Step 5: The employer enters 
information into form and 
clicks submit. 

Step 6: The system generates 
notifications/emails (based on 
preferences) passing information entered 
by employer. 

CONCUUSION: 

This use case concludes when the candidate has been notified (portaEemail) 
by the employer. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME: 

Communicate with potential 
candidates 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This use case describes how an Employer can conduct mass communication 
with all candidates who might be interested in a specific billet. (IE: New 
billet for an 0659 opens up, employer can communicate with all RBAS 
users with 06XX MOS.) 

PRE-CONDITION: 


TRIGGER: 

This use case is initiated when an Employer with roles clicks “Contact 
candidates”. 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step I: The employer selects 
“Contact candidates” within 
employer module. 

Step 2: The system will display an 
addressee block and free text form block 
to input the message. 

Step 3: The employer then 
selects addressees by criteria 
(rank, geo loc) and inputs 
message in message block. 

Step 4: The system transmits information 
to addressees. 

CONCUUSION: 

This use case concludes when the candidates receive communication from 
employer. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


Contact Candidate Process Model 


Addiliunal Kinail 
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Employer Subsystem 


USE CASE NAME: 

Create Employer Content for Portal 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Employer 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how an Employer can create a personalized web 
portal upon initial login to the Reserve Billet Advertisement System. 

PRE-CONDITION: 

The employer is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The employer logs into personal portal for the first time. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The employer logs on 
to RBAS for the first time. 

Step 2: The system prompts the 
employer to select what content they 
want to add to their personal portal. The 
user will be provided with a list of 
alternatives to select from. 

Step 3: The employer selects 
the services that he or she wants 
to populate their personal portal 
with. When the employer is 
done choosing, he or she hits 
“submit” to transmit settings 
back to RBAS. 

Step 4: RBAS acknowledges the request, 
and updates the employer’s preferences 
queue and updates the database. 


Step 5: The system sends a positive 
response acknowledging changes and 
instructs user to log off and back on to 
view the changes. 

AUTERNATE 

COURSES: 

None 

CONCUUSION: 

The employer personalizes their web portal. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME: 

Review Employer Content for Portal 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Employer 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how an employer can review the customizable 
information contained within their personal web portal (ie RSS feeds, 
content) 

PRE-CONDITION: 

The employer is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The employer reviews their personal settings within their RBAS personal 
portal. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: The employer selects 
“view” portal settings from 
menu of choices. 


Step 2: The system queries the database 
for the employer’s currents settings. 


Step 3: If the employer has personal 
settings, RBAS displays the queries 
results. 


ALTERNATE 

COURSES: 


None 


CONCLUSION: 


The employer reviews their personal web portal settings. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Review Employer Portal Settings Process Model 
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Employer Subsystem 


USE CASE NAME: 

Update Employer Web Portal Content 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Employer 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how an employer can update the customizable 
information contained within their personal web portal (ie RSS feeds, 
content) 

PRE-CONDITION: 

The employer is registered in the Reserve Billet Advertisement System and 
has been assigned the appropriate level of access. 

TRIGGER: 

The employer updates their personal settings within their RBAS personal 
portal. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The employer selects 
“update” portal settings from 
menu of choices. 

Step 2: The system queries the database, 
populates the list of alternatives with 
current settings. 


Step 3: The system prompts the 
employer to update their selections. 

Step 3: The employer selects 
the services that he or she wants 
to populate their personal portal 
with. When the employer is 
done modifying their settings 
he or she hits “submit” to 
transmit settings back to RBAS. 

Step 4: RBAS acknowledges the request, 
and updates the employer’s preferences 
queue and updates the database. 


Step 5: The system sends a positive 
response acknowledging the changes and 
instructs user to log off and back on to 
view the changes. 

AUTERNATE 

COURSES: 

None 

CONCUUSION: 

The employer updates their personal web portal settings. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME: 

Generate Advertisement History 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Employer 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how an employer can view a report which displays 
advertisement history information for all current applications. 

PRE-CONDITION: 

The employer is registered Reserve Billet Advertisement System and has 
been assigned the appropriate level of access 

TRIGGER: 

Employer views advertisement history report. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS: 


Step 1: The employer clicks on 
advertisement history report. 


Step 2: System queries information from 
all advertisements pertaining to that 
specific employer. 


Step 3: System displays results to 
Employer. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The employer is presented with report requested. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Advertisement History Report Process Model 
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Employer Subsystem 


USE CASE NAME; 

Generate Detailed Advertisement 

Report 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Employer 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION; 

This use case describes how an employer can generate a report which lists 
the details of all current advertisements. 

PRE-CONDITION; 

The employer is registered Reserve Billet Advertisement System and has 
been assigned the appropriate level of access 

TRIGGER: 

Employer views detailed advertisement report. 

TYPICAL COURSE 

Actor Action 

System Response 


OF EVENTS; 


Step 1: The employer clicks on 
detailed advertisement report. 


Step 2: System queries information from 
specific advertisement. 


Step 3: System displays all information 
on specific billet to Employer. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The employer is presented with report requested. 


POST-CONDITION: 


User is returned to portal homepage. 


BUSINESS RULES 


IMPLEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User must have access to NMCI compliant web browser. 


Detailed Advertisement Report Process Model 


Detailed 

.•\<h'crtisciTicnt 



Report 


Reqic»I ^ 

Employer 

Report 


Presetued 


- 


Detailed 

Advertisement 

Report 


Billet 

Advettiseiiient 
Histor)' (Jucry 


Qucr>' Rcsporeic 
- 


Billet Querv' 


Qucrv' Rcsp<in.sc 


Cutnmand Q«er>' 


Query Response 


At*»«nisemerr 



Biltet 



Command 



245 

























































Employer Subsystem 


USE CASE NAME: 

Generate Advertisement Response 

Report 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Employer 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 


DESCRIPTION: 

This use case describes how an employer can view a report which displays 
advertisement response information for all current applications. 

PRE-CONDITION: 

The employer is registered Reserve Billet Advertisement System and has 
been assigned the appropriate level of access 

TRIGGER: 

Employer views advertisement history report. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step 1: The employer clicks on 
advertisement history report. 

Step 2: System queries information from 
all advertisements pertaining to that 
specific employer. 


Step 3: System displays results to 
Employer. 

AUTERNATE 

COURSES: 


CONCUUSION: 

The employer is presented with report requested. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME: 

Generate Timed Report or Email (30- 
14-0-14) 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR 

Employer System 

PRIMARY SYSTEM 
ACTOR 


OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Employer 

DESCRIPTION: 

This use case describes how the system generates a temporal report/email 
which outlines the billets that will expire soon. 

PRE-CONDITION: 

Billets/Advertisements must be resident in the system. 

TRIGGER: 

System generates temporal reports. 

TYPICAU COURSE 

OF EVENTS: 

Actor Action 

System Response 

Step I: System runs query to 
determine which billets will 
expire within the following 
dates (30, 14, 0,-14). 

Step 2: System generates 
email/notification to employers that are 
responsible for those particular billets. 

Step 3: Notification/Email is 
received by employer. 

Step 4: System generates hyperlink to 
revalidate expiring billets if necessary. 

Step 5: If billets are not re¬ 
validated, system deletes 
billets/advertisements that have 
been expired for greater than 14 
days. 


AUTERNATE 

COURSES: 




CONCUUSION: 

Billets that are within the expiration window will be notified/deleted. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIFICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 
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Employer Subsystem 


USE CASE NAME; 

Manage candidate leads 

USE CASE TYPE 

System Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION; 

This Use Case describes how an Employer can manage all leads that have 
been generated for advertisements that are included in their purview. 

PRE-CONDITION; 

You must have the proper roles to be able to complete this use-case. 

TRIGGER; 

This use case is initiated when an Employer with roles clicks “Manage 

Leads” 

TYPICAU COURSE 

OE EVENTS: 

Actor Action 

System Response 

Step 1: Employer with roles 
clicks “Manage Leads” 

Step 2: Screen with listing of all current 
leads appears for the employer to select 
which one to manage. 

Step 3: Employer clicks on 
appropriate lead to obtain all its 
details. 

Step 4: System displays all details of 
specific lead. 

Step 5: Employer is given the 
option to update/delete the lead 
or return to the Leads menu. 


AUTERNATE 

COURSES: 


CONCUUSION: 

This use case concludes when the employer is successfully able to manage 
advertisement leads. 

POST-CONDITION: 

User is returned to portal homepage. 

BUSINESS RUUES 


IMPUEMENTATION 
CONTRAINTS AND 
SPECIEICATIONS 


ASSUMPTIONS: 

User must have access to NMCI compliant web browser. 


Employer Manage Candidate Leads Proeess Model 
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